For solo founders and very small teams, AI tools are the biggest productivity lever in years. They write code, draft text, summarise documents and build scripts. But the lever works both ways: what is produced faster can also be wrong faster. This article describes where AI genuinely holds up in running a small software company and the rules we apply.
The ground rule: verifiable results
AI pays off most where its result can be checked automatically or with little effort. Code can be tested, type-checked and built. Structured data can be validated against a schema. A website can be audited automatically after the build. Where that check is missing, AI merely shifts work from creating to checking — or, worse, to fixing errors at the customer’s end.
Where AI reliably saves time
- Code with tests: functions, migrations, components and refactorings, secured by type checking, tests and review.
- Operations tools: analyses, data clean-ups, check scripts and automations you would otherwise never have built.
- Structure for content: outlines, variants, translation drafts and summaries whose facts you take responsibility for.
- Support drafts: suggested replies based on your own documentation, read before sending.
- Research and orientation: a first overview of a topic, then checked against primary sources.
Where human responsibility must remain
Legal and professional statements customers rely on need a responsible person who has checked them — precisely because models phrase things convincingly even when wrong. The same applies to security-critical code such as authentication and tenant isolation, to decisions about customers and to anything understood externally as a commitment. For published text on matters of public interest, the AI Act also requires disclosure where there is no human editorial responsibility; details in our article on transparency obligations.
Customer data and AI tools
It is tempting for founders to paste customer data into an AI tool for a quick analysis. That is processing by a third party, often with a disclosure abroad, and needs a legal basis. The simple rule: with customer data, use only tools covered by a contract, with training on inputs excluded and a known processing location. For everything else, remove or anonymise the data first.
AI in the product is something else
AI for your own work and AI as a product feature follow different rules. In the product, tenant isolation, cost control per customer, evaluation, protection against prompt injection and AI Act obligations come in. Building it robustly is covered in our article on the Next.js App Router in production and in our checklist on LLM feature production readiness.
The hidden costs
AI lowers the cost of creating and raises the cost of maintaining, if you are not careful. More code means more code to understand, update and secure. More content means more content to keep current. The yardstick is therefore not how much AI produces but how much of it is still correct, maintained and useful a year later. Less, better checked, beats more, unchecked.
Our rules
1. Use AI where the result can be checked automatically, and make the check mandatory.
2. Take personal responsibility for every professional and legal statement and check it against primary sources.
3. Customer data only in tools with a contract, no training and a known processing location.
4. Always review security-critical code, regardless of who or what wrote it.
5. Measure what still holds up after a year, not what was produced in a week.
How this fits into a working rhythm is described in our article on the weekly rhythm of a solo founder. For teams wanting to introduce AI in a structured way, we offer an AI integration strategy.