Building Internal Tools With AI: a Bootstrapped Team’s Honest Account (NOT a Case Study!)

We are a small SaaS company competing with companies ten to fifty times our size. You have definitely heard of Asana, Monday.com, or ClickUp – these are all our competitors. The only difference is that we are 25 people, bootstrapped, and they have billions in investments.

We have been in the project management market since 2013, and our main advantage over our competitors is speed. If we move fast, we can take some part of the market. If not, we will just disappear. That is the context. Let’s get to the main story.

In February this year, we built our own internal system for tracking time, salaries, holidays, days off, and contracts to replace our old legacy system. It is built with Lovable, with no single line of code written by hand. Since March, our whole team has been using it every day.

This is not going to be the ninety-second demo story, where somebody types a prompt, an app appears, and software engineering is over. I have been with Kanbanchi for almost 11 years, and out of everyone here, I was probably the most nervous about this project, because it manages how people get paid for their work. I want to share an honest account of what we got, what breaks, and where, in my opinion, is the line between building your own tool and simply buying something that already exists.

What We Had Before

If you read my post on how to effectively manage remote employees, you know that we are a distributed team, so tracking the time has always been part of how we keep things fair for the employees and for the company.

However, in that blog post I didn’t say anything about the software we use, only the trust we give our employees. Maybe those who read it noticed that the interface looked outdated. It was also very heavy and was only capable of doing one thing – logging the time. All other processes around that, like calculating payments, storing contracts, tracking vacations and days off, were outside of that software.

Just the time log. This is what the old system was doing.

• No reporting
• No payments or balance calculation
• No tracking of days off and vacations
• No links to necessary tools and contracts, etc.

We could have added these features, but it would have taken months of development time. And we thought it would be better to invest this time elsewhere and use a no-code platform instead. Adding the same features took hours.

Another reason for choosing Lovable to build our new tool was that we were interested in vibe coding. We needed that experience, and we got it. So, now we don’t just have a time-logging app, but we have our “Hub”. Yes, that’s how simple we called it.

How We Use the Hub

Today the team uses the Hub to:

• Log work time, which is the main everyday function used by everyone
• Check payments for the past period and balance
• Request days off and vacations, and check the shared calendar to see when colleagues are available
• Request access to the tools and services available for team members 
• Find contracts and the reference information that used to live in five different places
• Share insights gained from doing their job

This is just the feature list; it is not the most interesting part. What people actually praise is that everything is in one place now. Before, we had to log hours in one system, check who was on vacation in the corporate Google Calendar, and request access somewhere by filling out a Google Form. In a few words: now all is in one place, with a clear interface. That may sound boring, but that is what people actually feel every day.

Also, it has a feed where you can see what other people worked on and what insights they got. Sharing experience is now more explicit, and sometimes not so nice. But that is the transparency we want in our team and that we value.

The Reports Feed in our Hub. Alongside their hours, people log what went wrong, what went right, and what we should do differently. Everyone in the group can read it. Names blurred here, expressions saved.

What AI Did Right, and Where It Adds Value

Speed, obviously. However, I want to be precise about what kind of speed.

The distance between “we should track balances” and “we track balances” was hours, not months. For a small team, like ours, this changes what is even worth trying. All the ideas that are nice to have, but not crucial, and that would never survive a months-long build, suddenly get implemented, because the cost of trying is one morning.

It also wasn’t prompting into the void. The person who built it worked from written specifications: business goals, data, and user flows documented before anything gets built. And when we got to the sensitive parts, we asked professional developers to review the code and audit security. They found issues, and we fixed them.

So speed refers to the coding itself, because no line of code was written by hand. That doesn’t mean nobody was taking time to think about what we were building.

What Breaks, And What We Do About It

This is a part that makes this article an honest account rather than a case study.

The Hub works well most of the time, but sometimes not exactly as designed. It’s a vibe-coded app. I haven’t yet seen one that functions exactly as it should. Let me know if you know any.

The weak spot is unfortunately precise calculation, which is the most important part. No, it handles standard cases well, but sometimes it can’t be trusted with a non-standard situation. One month it showed me that the company owed me $2,000. I would love that to be true! It was a mistake 😔

Also, one day the “Request payment” button stopped working, and people couldn’t request earned money. This is definitely not a “let’s look at it next month” bug.

I should admit, in the beginning I didn’t put a lot of trust in it, because it touched payments. I duplicated everything into a Google document, just in case the data disappeared and I had to prove what I worked on.

How Our Past Experience Helped Us This Time

We learned something about moving fast a few years earlier. I remember when we integrated a new payment provider very fast; it took us days instead of weeks, because their API allowed that. I will be honest, we were proud and glad that we could receive payments from clients in a way they wanted. But it happened that we forgot to remove the old payment system, and some people were still buying through that flow. Later, when we were reconciling yearly revenue data, we saw that the data didn’t match. It wasn’t a disaster, but it added some hard work.

After that, we started questioning our processes, reviewing them, and we distinguished two zones. One is kind of a “sacred” zone, which is customer data, billing, security, etc. This is where we follow strict checklists, double-check, and move carefully. The opposite zone is our experimental ground. This is where we move fast, run A/B tests, check hypotheses, change interfaces, etc. And, of course, there’s no black and white, as usual. Most of the tasks are somewhere in between, and you need to balance.

An internal payment system sits somewhere in between. It’s not related to customers, but it’s the company’s reputation among people who work for us.

How We Keep It Running Now

There are two things that make the Hub manageable rather than a time-consuming project:

1. A bug tracker inside the app. When anyone notices something wrong, or thinks of an improvement, they leave a note inside the Hub, and it goes straight to the developer. There are no official testers or a scheduled time for testing. Everyone who uses it is the tester, and everyone can report bugs or share ideas. People who use this tool every day find the strangest things and have better ideas than the one who built it.
2. Prioritization. Every tool has bugs, paid or free, vibe-coded or solely written by humans, recently created or existing for decades. The difference is the sequence these bugs will be fixed in. The “Request payment” button was fixed within hours; some cosmetic bugs are postponed because they don’t affect anyone’s work. If we used a third-party tool, we could have filed a ticket and waited until it’s added to the roadmap. Here we can create our own roadmap.

The bug tracker inside the Hub. Anyone can report something in ten seconds. Of 36 reports so far, 25 are fixed, and 6 are deliberately marked “won’t fix”, because we prioritize what gets attention and in what order.

There is still one limitation, but it’s not a bug: AI is still extremely weak at interface design. The majority of employees say that the time logging screen has too much on it. They use only about 20% of that screen 90% of the time, but they have to scroll down for the “Save” button. AI still needs humans to decide what is important for humans.

The Cost of Vibe Coding

Since it’s an honest account, let me be specific about money. We care about this part, perhaps, more than any other company, because we are bootstrapped and this is a very important question for us.

Credits are not cheap, and the billing is hard to predict. Using Lovable for around two hours a day can easily run up €600 a month in extra credit top-ups. For comparison, our developer’s $125 Claude plan gives more mileage for the money. However, the amount of money itself is not the biggest problem, but the transparency: with the credit system, you never know how much a task actually will consume. As a result, you can’t properly plan, and you can’t fully trust the model.

If you still think that no-code means cheap, that could disappoint you. However, you should always calculate the expenses against solutions that you can buy.

The Line Between Building and Buying

Don’t skip this part if you already want to go and build something.

AI has made building comparably cheap, but if it’s cheap, it doesn’t automatically become worth building. These two different things are constantly confused.

Our Hub makes sense, because it is wired to how we specifically handle pay, balances and leave, and there is nothing off the shelf that would fit. We know that our Hub is genuinely bespoke, because the way our company pays its contractors differs from large companies. And most of the software of this kind is made for large companies.

That is the situation where building your own earns its place: the thing is yours, it doesn’t exist yet, and you want to control how it works. This secret is actually not new; we learned that more than thirteen years ago when we created Kanbanchi as the solution for the problem we had, but then solved the same problem for many businesses.

What we would never do is build for the solved category. So the line I would draw is this: build when it is bespoke and buy when there are plenty of established solutions. AI dramatically lowers the cost in the first case, and that is what I am genuinely excited about. For the second case, it’s useless.

What Actually Made It Work For Us

1. We knew exactly what we needed. We had our old system for years, so we weren’t inventing requirements; we just documented all the complaints and ideas that we collected for a decade. In our case, that was a great foundation we built on.
2. We kept the risky part supervised. Professional developers do security checks; we still have humans to check and make payments every month. We are following our rule of separating zones: this is a sacred zone.
3. Reporting a problem or sharing an idea takes ten seconds. People can report bugs while they are annoyed and when they can share all the details. They can even use voice input, so it literally can take ten seconds. If it had required an email to the developer, most of those bugs would still be there.

If You Want To Try Vibe-Coding…

I asked our team what they would tell another small company thinking about vibe-coding their own tool. Almost everyone said “go for it”, but added the same condition, in their own words.

– Start with understanding everyone’s needs to avoid redoing stuff later.

– Go for it, but first identify the goals and gather requests and expectations from the team.

Everyone in our team was building software without AI, and now AI is another useful tool for doing what they are professional at. They understand that the hardest part is not the building; it’s designing how a feature should behave, and clearly explaining that logic to AI to actually build it. This is what the creator of the Hub also called the hardest part: explain what exactly is working wrong and what the right way is.

Where we made that step wrong, we paid for it with the calculation bugs I described earlier and with rework and Lovable credits.

Let me summarize it in a short checklist:

• Gather the people you want to build for, and ask what they actually need before you write a single prompt. Chances are they know their own work better than you do
• Always keep in mind what happens if your app works wrong. What are the consequences?
• Bring a professional in for a security check
• Don’t invent the wheel: build something bespoke

FAQ (I Used AI For Writing It as a Summary for this Article)

Is building internal tools with AI reliable enough for real work?

In our experience, yes, with supervision. Our Hub has been running our team’s time, payments, and leave tracking since March. Everyday functions like logging time and checking a shared calendar are solid. Precise calculations in non-standard situations are where it is weakest, so anything involving money still gets a human check.

Should you build an internal tool with AI or just buy one?

Build when it is bespoke and no existing tool fits, especially internal systems tied to how your specific team works. Buy when the category is mature. AI makes building cheap, but rebuilding a solved category means taking on all the maintenance and security yourself, when an established product has already absorbed years of other people’s edge cases.

What is the hardest part of building an internal tool with AI?

Not the code. Specification. Working out exactly how each feature should behave and explaining that logic clearly. After that, scope creep, because building is so fast that teams end up building far more than they intended. Mapping requirements with the whole team first is the single most useful step.

How much does it cost to build an internal tool on a no-code AI platform?

Less than a traditional build, but not free. Credit-based billing adds up faster than people expect: around two hours of daily use on Lovable can mean roughly €600 a month in top-ups, while a $125 Claude plan goes considerably further. The credit system also makes spending hard to predict. The comparison that matters is against the separate subscriptions the tool replaces, and for us, consolidating time, salary and leave tracking into one system we control came out ahead.

Do you still need developers if you build with AI?

For a working tool, not necessarily. For a safe one handling sensitive data, yes, at least for review. We had professional developers audit security and fixed what they found. No-code doesn’t remove the need for expert judgment; it just changes where you spend it.

My Conclusion

Would we do it again? Yes, and we are already. The Hub is not the only project that we are building with AI.

Would we build everything with AI now? No. And knowing the difference between these two cases is probably the most valuable insight of this project.

On a Side Note

Interested in Kanbanchi? You can try. Want to check if there are any other thoughts from my colleagues on AI and automation, or from me? Check this from time to time 😉