From proof of concept to standstill, and back: an online bookkeeping service

A company turned a quick proof of concept into an online bookkeeping service, and found customers fast. Then performance complaints came in, nobody knew why, and development came to a halt. By putting an architecture in place and rebuilding control step by step, the performance issues were fixed in a short time, and development got back on track.

At a glance

Organization	Software company offering an online bookkeeping service to other businesses. A small to medium-sized business with a small development team (2–3 developers).
Situation	Struggling with a fast-grown application, built on a no-code platform
My role	Consultant: understanding the problem and coming up with a solution
Duration	1–2 days to understand the problem; the fix took a few weeks
Result	Performance issues fixed by putting a solid architecture in place; development fully under control again

The situation

The company built a system to support their own bookkeeping, set up from the start so it could also be sold as an online service to other companies. It began as a small proof of concept. That proof of concept turned into the actual application, all built in a reasonably short timeframe on a no-code platform.

And it worked: the application worked fine and they got customers. Everybody happy, right?

The problem

Well, yes, until the first performance complaints came in. The system became too slow to work with, but nobody really knew why. And nobody dared to touch it, afraid that things would only get worse.

The result: development basically came to a halt. No new features, and increasingly unhappy customers.

As it turns out, the company had made a few classic mistakes when using a no-code platform to build an application. The first, and most crucial, was that they started with a proof of concept (POC) and used it as the basis for their development. The POC was put together really fast, by someone who had never developed software before. Impressed by the development speed and the result, they decided to keep the POC, bring in two other citizen developers (also without a software engineering background), and just add more and more features.

At some point they got customers, the system was used more and more, more data came in and needed to be processed, and the system became slower and slower. Until the moment their customers couldn’t work with it anymore.

Because the company didn’t have the knowledge to figure out what was wrong, they no longer dared to touch the software. That effectively stopped development, and left them unable to fix their customers’ problems.

The approach

First, we took a step back instead of diving into the code:

1. Inventory. What was important, and who owned what. Which features were crucial, and which were still needed.
2. Specifications. We wrote down what the system should do, and checked those specs against what had already been built, so we knew what to work on. There were no specs when I started on this project.
3. Architecture. The crucial finding: there was no architecture. The application had grown from a proof of concept by adding functionality on top, and the lack of architecture had exposed severe issues in how data and security were handled (and several other, less critical issues). So we put an architecture in place, with the rules that would need to be applied.
4. Step by step. We checked the specs against the existing application, and either updated existing features or added new ones, fully controlled and based on the new architecture. Basically, we rebuilt large parts of the software, reusing what we could wherever possible.
5. Governance. Rules and checks were set up to guide the team, so the same situation wouldn’t build up again.

The result

The performance issues were fixed within a month, and development restarted, this time fully under control, guided by the architecture and governance rules we had put in place.
From there on, they were able to onboard new customers and grow their business.

What I’d do differently

The key issue here was twofold: no architecture, and no software engineering knowledge. They trusted their knowledge of the product they wanted, and the no-code platform to build it on.
What they should have done:

• Write specs of everything they needed in the software.
• Define their customers, and how those customers would use the software.
• Find out which security guidelines they needed to adhere to.
• Put together an architecture based on the specs, customers, security, data size, and so on.
• And only then start building the solution.

And yes, make sure you have basic governance in place, so the entire team knows the rules and responsibilities.

Does this sound like your situation?

Is your application growing faster than its structure? The Low-code and AI-assisted development health check shows where you stand today, and what to do next. Or read Your AI-built app is getting out of hand. Now what? for the broader picture.