Everyone says SaaS is dead. As many have already pointed out, AI will likely separate “glorified spreadsheets” from genuinely useful SaaS products. Software that is easy to build will no longer be able to charge $10 per seat when anyone can replicate it with a single $20 Claude subscription. Enterprise software for thousands of employees is a different story: keeping it secure and reliable is still hard.
But perhaps your company isn’t an international bank. Perhaps you can cut a few corners to keep costs down. Your software might need little maintenance, or your company might have only a handful of employees, so a simple “glorified spreadsheet” is good enough.
To find out how far this goes, I set myself a challenge: given a real software specification, how easily can I build it with Claude without really touching the code? And how reliable is the result?
The plan
- Laying the foundation
- Gathering requirements
- Prompt, test, repeat
- Previewing the final product
1. Laying the foundation
There’s no need to start from scratch, since plenty of frameworks can serve as a base. As long as the framework is decent (not slow, for example), the choice barely affects the end user. I went with Hubleto, an open-source PHP ERP that already ships with plenty of apps we can build on. Full disclosure: I am associated with Hubleto.
For comparison, I asked Claude for alternatives. It suggested:
- Twenty
- EspoCRM
- SuiteCRM
To learn how to install Hubleto (and how to use it even if you don’t need custom apps), watch this video:
2. Gathering requirements
With Hubleto installed, the first step is to find out what the client actually wants. For this demonstration, we’ll build the following use case:
The client, which I’ll call AlgoCorp, offers security training both to its own employees and to employees of other companies. Each training has multiple sessions (dates), applicants (also called workers), orders and certificates.
This is only a summary. The full requirements specification, along with every prompt I used, is available at https://github.com/mibarnas/hubleto-ai-experiment/blob/master/report/blog.md. Each commit corresponds roughly to one prompt.
3. Prompt, test, repeat
With the specification ready, it was time to let the AI do the building. I used Claude Opus 5 on High effort, which is included in the $20 Claude Pro subscription at no extra cost.
The first prompt was simply:
You are given a freshly installed Hubleto instance. Plan the following features.
Enter fullscreen mode Exit fullscreen mode
followed by the requirements specification. Opus 5 first drew up a plan, which the cheaper Claude Sonnet 5 (also on High effort) then executed.
Even the first result was surprisingly good. Claude correctly identified that it needed four custom apps: Certificates, Questionnaires, Trainings and Workers. More importantly, it also delivered the front end, which is what we care about most.
The forms it created were complex, functional and good-looking, almost flawless. Some functionality was missing, though: certificate generation, statistics and the externally accessible survey were all in the specification but hadn’t been implemented. Claude also struggled to combine Hubleto’s stylesheets with its React components, so the tables ended up with odd black borders.
From here, the most important work was testing everything and reporting the issues. Over the next few prompts, I gave Opus 5 more detail about the bugs, the architecture and the requirements. This way, I finished the project in a single person-day.
4. Previewing the final product
Now it’s time to evaluate whether the software:
- does what we wanted,
- is free of errors, and
- is reliable and well executed.
Note that code quality and readability are out of scope here.
The software Claude built covered everything that was commissioned:
- A clear overview of questionnaire answers, linked to the training participants.
- A list of workers who are taking or have taken trainings, with their trainings, schedules, certificates and orders.
- A list of trainings, each with its schedules (sessions) and attendees, plus a certificate template that is automatically checked for placeholders.
- A list of training orders for billing, with links to the participating workers and support for both B2C and B2B invoicing.
- Fully functional, externally accessible surveys for participants who have completed a training.
Most of the issues from the previous section were fixed. The questionnaire is now accessible, can be submitted, and its answers are saved. The black borders are gone too, though not in the way I originally intended. A few problems remained: the certificate download didn’t work properly, and certificate generation failed, possibly because of the LibreOffice package.
Claude successfully identified Hubleto’s existing models and linked them together, but it didn’t always get it right. For example, each training order had buttons to create an invoice and a project, and neither of them worked. Claude also confused its own training orders with Hubleto’s built-in Orders app: refreshing the page while a training order was open broke it, and the order wouldn’t load again until it was reopened manually.
Conclusion
So, back to the opening question. Building business software is clearly far less demanding than it used to be. Even for a skilled programmer, implementing a few interconnected models and their views now takes a single prompt and a few minutes, if not seconds.
Some say AI is too limited and is the bottleneck in our work. Others say humans will become the bottleneck and AI will soon replace us. I think both are partly true. AI models are still far from perfect and will need to improve a lot before they could replace us, if they ever do. At the same time, we often expect them to achieve what we can’t achieve ourselves, while failing to reflect on our own mistakes.
In my free time, I’ve built two passion projects with Claude, one of which is a Summer Camp Planner. It builds on the spreadsheet we previously used for camp planning, adding a timeline, an activity database, better collaboration, daily reviews for camp leaders and more. Claude handled all of it flawlessly: every iteration was mostly bug-free, apart from the occasional odd UX/UI decision. The camp planner differed from this project in its setting, and it was built on Laravel rather than Hubleto.
Honestly, developing with Hubleto felt clumsier than with Laravel. The comparison isn’t entirely fair, since I had been working on the camp planner for much longer, but that process was far smoother, with fewer problems caused by the framework itself (such as the stylesheet issue).
On the other hand, as mentioned earlier, Hubleto ships with a wealth of ready-made apps. Technical hiccups aside, this saves a lot of tokens: the sidebar, the app interfaces and even some complete apps are already in place.
So, to finally answer the opening question: yes, building business software is much easier now, and the result can be reliable. But its success depends on the foundation you choose, how well you plan, and how well you deploy it (remember the LibreOffice issue?).
Tips
Finally, here are a few tips I found useful:
- Plan with a strong model, execute with a cheaper one. To avoid burning through credits on Fable, I had Fable plan a few requirements at a time and let Opus 5 execute the plan.
- Size each prompt to fit one session. Only give the model as many requirements as it can finish in one session, then start a new one. Otherwise it rereads the entire history every time your session limit resets, which wastes a lot of tokens.
- Start new chats often, at the very least whenever your session limit resets.
- Use Fable for UI design. It was much better at designing user interfaces than Opus 4.8.