Can Claude Build Your Business Software in a Day?

A developer used Claude Opus 5 and Sonnet 5 to build a custom ERP application on the open-source PHP framework Hubleto from a real client specification in a single person-day, with the AI correctly identifying four custom apps and delivering functional front-end forms. The experiment found the generated software covered all commissioned features, though certificate generation and download remained broken and some styling issues persisted. The developer notes an association with Hubleto and published the full requirements, prompts, and results on GitHub.

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? 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: To learn how to install Hubleto and how to use it even if you don't need custom apps , watch this video: 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 https://github.com/mibarnas/hubleto-ai-experiment/blob/master/report/blog.md . Each commit corresponds roughly to one prompt. 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. 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. Now it's time to evaluate whether the software: Note that code quality and readability are out of scope here. The software Claude built covered everything that was commissioned: 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. 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 https://tabory.barnas.net/ . 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? . Finally, here are a few tips I found useful: