Under the hood, a well-designed custom-built solution almost always comes down to four building blocks: a lightweight interface, an engine — an AI model run locally or called via API depending on data sensitivity —, a simple database, and, optionally, a conversational agent that queries the whole thing in natural language. FiscalDoc, the application I built to organize my own tax filings, illustrates this pattern in its most stripped-down form. What follows generalizes this architecture, and honestly explains what makes it grow.
What are the four components that come up almost every time?
The first building block is the interface: the front end through which a user submits information or reads a result. In FiscalDoc, it's a simple web form — I upload a PDF or a photo, and the tool takes care of the rest. At this scale, nothing justifies a heavy front-end framework or a native mobile app: a clean form, a filterable table, and a few buttons cover nearly all of an SME's internal use cases. Visual sophistication becomes useful mainly when people outside the company use the tool — which changes things, as I'll come back to later.
The second building block, the engine, is the choice that shapes everything else. An open AI model, run locally, becomes necessary when no data may leave the company — that's the choice I made for FiscalDoc, with an open model running on my own Mac, without a single network call for the core processing. An API call to a proprietary model, conversely, remains perfectly defensible when the data being processed is not very sensitive and speed of implementation matters most. Between the two, there's no universal answer, only a trade-off specific to each use case, which I detail in A Well-Built AI Project: The Three Patterns That Hold Up — direct calls, RAG, and agents are laid out there as the three patterns that cover most projects, regardless of the local-versus-API choice.
The third building block, the database, often surprises with its modesty. FiscalDoc indexes several hundred documents a year in a local SQLite database — a file, not a server. For use limited to a handful of users and a few thousand records, a simple database does the job one might assume requires heavy infrastructure. Moving to a more robust system — a hosted database, replication, automated backups — only becomes necessary once several people are writing at the same time, or once volume exceeds what a single machine can comfortably handle.
The fourth building block is optional, and it's important to say so clearly: a conversational agent that queries the database and documents in natural language. In FiscalDoc, I can ask it to find MCVA invoices over CHF 2,000 from the last quarter and get an answer built on the fly. This layer adds real convenience, but it's never the first thing to build: a filterable dashboard already covers most search needs, and a conversational agent only justifies its development cost when the questions asked are genuinely varied and unpredictable.
Where should these four building blocks be hosted?
The hosting choice follows directly from the engine choice, not the other way around. A local machine — a workstation with adequate memory — is enough for individual use or a small team, with an open model that never connects to the internet for core processing. Swiss or European infrastructure becomes relevant once several users need to access the same tool from different workstations, without wanting to hand the data over to a cloud outside their jurisdiction. A vendor cloud with contractual non-retention commitments remains a reasonable option for the least sensitive data, when speed of implementation matters more than full control over where processing happens. I laid out this three-tier framework — contractual commitments, Swiss or European hosting, open model on controlled infrastructure — in the article on AI project architecture, and I revisit it at the start of every custom-built solution engagement.
Why do a few hundred lines of code often suffice?
FiscalDoc fits in a folder of a few hundred lines of code. That's not a feat — it's the direct consequence of a scope kept deliberately narrow. A tool serving one user or a small team, for a precise and well-described function, doesn't need to handle thousands of simultaneous connections or anticipate cases that will never occur. The most cost-effective discipline in this kind of project is resisting the temptation to build for a hypothetical use rather than for the real need identified at the outset.
What has also changed, over eighteen months, is the cost of production itself. I didn't write FiscalDoc line by line: I built it in dialogue with a coding assistant, evening after evening, until I got a tool that fits me — I detailed this method in my account of AI-assisted development. What I demonstrate at the scale of a one-person practice, the same logic allows, function by function, for broader SME needs. The full case — costs, trade-offs, limits — is documented in FiscalDoc: Replacing CHF 1,400/Year of SaaS with Local AI.
What makes a project grow?
To date, I've publicly documented only one complete case built according to this pattern — FiscalDoc. But its architecture is anything but accidental: it corresponds to what remains once the superfluous is stripped away, and it changes as soon as one of the following three conditions shifts.
- Integrations. Connecting the tool to an existing accounting system, an ERP, or a business mailbox multiplies points of failure: each integration adds its own interface contract, its own error handling, and its own ongoing maintenance.
- Multiple users. As soon as several people need to access the same tool with different permissions, you need real authentication, role management, and often an audit trail of who did what — a project in its own right, distinct from the business logic itself.
- Compliance. A tool that touches third-party data — clients, employees — brings the FADP (Federal Act on Data Protection) into play beyond the simple hosting choice: a record of processing activities, a data processing agreement if an external component is used, a retention policy. This work deserves to be addressed during scoping, not discovered along the way.
None of these three triggers rules out a custom-built approach. They change its budget and rigor, not its relevance. What they do invalidate is the idea that a project of this kind can always be settled in a few evenings: past that threshold, scoping deserves the same rigor as a SaaS project of equivalent scope — which is exactly what I set out at the start of every custom-built solution. This anatomy is just one piece among others: the overall roadmap is laid out in What Should a Swiss SME Do About AI in 2026?
Key takeaways
— A custom-built solution almost always comes down to four building blocks: a lightweight interface, an engine chosen according to data sensitivity, a simple database, an optional conversational agent. — Hosting follows the engine choice: a local workstation, Swiss or European infrastructure, or a vendor cloud under contractual commitments. — Three triggers make a project grow: integrations, multiple users, compliance — they change the budget, not the relevance of the custom-built approach.
FAQ
Should a local AI model always be preferred over an API? No. Local becomes necessary when no data can leave the company; the API is often faster to implement for less sensitive data. It's a case-by-case trade-off, not an absolute principle.
Can an SME with no internal technical skills consider this kind of tool? Yes, provided a competent third party leads the dialogue with the coding assistant and reviews what's produced. The deliverable — code and data — then belongs entirely to the company, which remains the central benefit of the approach.
How long does a project like this take? It depends entirely on scope: a few evenings for a need as narrow as FiscalDoc, several weeks once integrations or multiple users come into play. No general figure would be honest without prior scoping.
Is a database as simple as a local SQLite database really reliable for an SME? For use by one or a few users and volumes of a few thousand records, yes, comfortably. It reaches its limits once several people write simultaneously or volume exceeds what a single machine can comfortably handle — the very signal that a change of scale is needed.
What about your company? The AI Usage Diagnostic: sixty minutes to map your actual workflows, identify what deserves a custom build, what stays in SaaS, and what needs no AI at all. Book a diagnostic
Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.