Local execution
The working dataset was used on the computer to generate the report.
Business Software · Desktop reporting
Building AI reports while keeping business data local
An early-stage desktop product used sample data to generate report code in the cloud, then ran that code against business data locally. Weekly demos helped turn a command-line utility into a usable application.
The business context
The report needed AI assistance. The working data needed to stay on the computer.
A product founder wanted to make reporting accessible to people who could describe the analysis they needed but could not build it themselves. For the intended users, uploading a complete business dataset to a cloud model was an obstacle. The product had to separate help with creating a report from access to the records used to populate it.
The initial request was deliberately small: a Windows executable that would run an analysis and produce an Excel output. Shinetech first implemented that basic utility, then used working demonstrations to explore whether a command-line experience was sufficient for the people expected to use it.
System view
A reporting request with a visible data boundary
This concept view illustrates the separation between a sample used for generation and a dataset used locally. Code, values, labels, and interface controls are illustrative, not the customer’s implementation. View full-size interface (new tab)
The operating challenge
A technically working utility still left the user with too much to interpret.
The central design decision concerned what crossed the cloud boundary. Sample data and the reporting request could describe the required structure. The model would return report code; the real dataset would remain on the local machine where that code ran. This made the location of the data part of the product workflow, rather than a privacy statement added after development.
There was also uncertainty about the product itself. Model selection and prompt behavior needed repeated trials, while the founder’s expectations evolved after seeing the first version. The team had to improve usability within an existing budget, without turning an exploratory tool into an open-ended platform build.
The delivery decisions
Keep the data boundary visible as the product grows.
Separate code generation from data execution
The implementation used sample data to help the cloud model generate inspectable report code. Local execution then read the business records and produced the report. That separation preserved a practical role for a cloud model while keeping the working dataset out of that reporting request.
Use a working demo to decide the interface
After completing the simple utility, the team proposed a desktop interface and demonstrated how it would support the reporting task. The customer could assess a functioning interaction instead of having to decide the complete product from an abstract feature list.
Package the agreed workflow as a desktop application
Node.js and Electron provided the foundation for the PC application. The engagement moved from a minimal executable to an installer-based deliverable, with the interface improvements completed within the agreed budget.
The working detail
The prototype was also a way to clarify the product.
Weekly demonstrations
Regular meetings and demos exposed the difference between a simple implementation request and a useful reporting experience. They helped the team discuss concrete behavior as the customer’s expectations changed.
The useful lesson was the order of decisions: first establish the reporting operation, then refine how a person uses it. The delivered architecture made generated code available for inspection, but the project record does not establish an automated security review or an execution sandbox. Those would require their own requirements and verification.
The delivered result
A desktop reporting application was delivered within the project budget.
Visible interaction
The delivered product developed beyond the original command-line utility.
Completed handoff
The customer received the PC application installer.
The documented endpoint is installer delivery. Subsequent adoption, commercial performance, and ongoing production use have not been confirmed.
Case taxonomy
Searchable by industry, technology, product, and business need.
Industry and product
- Business Software
- Desktop reporting
Technology and delivery
- Node.js
- Electron
Business need
- AI-assisted reporting
- Local data processing
- Desktop application
- Product discovery
Discuss your project
Where should AI help with a task, and where should your business data stay?
Tell us how your business works and where your software needs to change.
Get in touch
Ready to build software that fits your business?
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review