Why we build internal tools first

Most products do not begin as products. They begin as internal tools — small, unglamorous pieces of software built to solve a problem that was standing directly in front of us. The kind of thing nobody outside the team was ever supposed to see.

A script that removes a repetitive task. A dashboard that answers a question we keep asking. A small system that replaces a spreadsheet. A utility that saves ten minutes every day.

None of these things sound particularly exciting. But sometimes, they become the beginning of something much bigger.

We have started to believe this is not an accident. It is one of the most natural ways useful software gets discovered.

§Why build for ourselves?

There is a fundamental difference between building something for yourself and building something because you think somebody else might want it.

When we build for ourselves, we don't have to begin with a hypothetical user. We are the user. That changes the feedback loop completely.

If something is confusing, we experience the confusion. If a workflow takes too many clicks, we repeat those clicks. If a feature is unnecessary, we feel the weight of it. If something breaks, there is no need for a survey to tell us. We know.

This makes building for ourselves unusually honest.

There is also an important limitation here. Being your own user does not mean you automatically understand everyone else's needs. It simply gives you a much better place to start.

Instead of beginning with what should we build?, we can begin with what problem keeps getting in our way? That is a much more concrete question.

§Start with friction

Most internal tools are born from friction.

Something is taking too long. Something is being done manually. Something requires copying information from one place to another. Something keeps breaking. Something requires opening five different tools to accomplish one simple task.

At first, the problem may not even feel important enough to become a product. You just want it gone. So you build something. Maybe it takes an afternoon. Maybe it takes a weekend. Maybe it is just a small script.

The first version does not need to be beautiful. It needs to remove the friction. That is an important distinction.

We are not trying to build the final product. We are trying to understand whether solving the problem is valuable.

§The first version should be allowed to be ugly

There is a strange pressure in modern software development to make everything presentable immediately. The repository should be clean. The UI should be polished. The architecture should be scalable. The landing page should be ready. The documentation should be complete.

But an internal tool has a different job. It is an experiment.

That does not mean we should write careless software forever. It means we should avoid solving problems we do not yet know exist.

If the tool is useful, the next version can become better. If it is not useful, we have learned something without spending months polishing it.

§The feedback loop is the real advantage

The most valuable property of an internal tool is not that it is internal. It is that it creates a tight feedback loop.

There is very little distance between an idea and reality. You don't have to write a fifty-page specification before learning whether the workflow makes sense. You don't have to convince a hypothetical customer to try it. You don't have to predict every edge case.

You build something. Then you use it. And reality starts giving you answers.

§Use the product before explaining the product

This is one of the reasons we like internal tools. When you build something for other people, it is tempting to spend a lot of time explaining what the product will do. When you build something for yourself, you can simply observe what it does.

The product starts teaching us what it should become. That is much more valuable than designing the entire thing from assumptions.

§The tool tells you what matters

A useful internal tool creates evidence. Not perfect evidence, but better evidence than imagination.

If we build five features and people repeatedly use only one, that tells us something. If everyone keeps creating workarounds for a particular step, that tells us something. If nobody uses a feature we thought was essential, that tells us something too.

Usage does not answer every product question. But it gives us signals. And signals are valuable when deciding what to build next.

This changes the role of engineering. Instead of engineering being the final step after product decisions are made, engineering becomes part of the discovery process. We build in order to learn.

§Internal does not mean unfinished

There is another distinction we care about. An internal tool is not necessarily an unfinished product. It can be a complete solution to a small problem.

If a tool solves exactly what the team needs, there is no reason to add a public landing page, a billing system, a multi-tenant architecture, or twenty configuration screens. Those things may become necessary later, but they are not automatically improvements.

A tool can be small because the problem is small. And that is perfectly fine.

§Not every internal tool should become a product

This is probably the most important caveat. We don't believe that every useful internal tool contains a startup inside it.

Sometimes the problem is too specific. Sometimes the solution depends on internal context. Sometimes the workflow exists only because of the way a particular team operates. Sometimes there simply isn't a large enough problem outside the organization.

And that is okay. The purpose of building internally is not to manufacture product ideas. It is to discover whether a problem is worth solving. If the answer is no, we stop. If the answer is yes, we investigate further.

§When does an internal tool become a product?

There is no single moment when this happens. But there are signals.

That last one is perhaps the most important. That is when the question changes. We stop asking is this useful to us? and start asking is this problem shared by enough people that it deserves to become a product?

§Build the problem, not the product

This distinction has changed how we think about product development.

It is easy to fall in love with the product idea. The name. The interface. The architecture. The features. The technology. The pitch.

But all of those things are downstream of the problem.

So we try to keep the problem visible. Before building a feature, we ask what problem does this solve? Before adding complexity, we ask what would happen if we didn't build this? Before building an abstraction, we ask have we seen this problem enough times to justify the abstraction?

These questions are not glamorous. They are useful.

§The first user is often the easiest user to understand

When we build internally, the first user is close. That makes conversations much easier.

We can ask why didn't you use this? and get an answer immediately. We can watch someone use the tool. We can see where they hesitate. We can notice the workaround they created. We can hear the complaint they make after using it for a week rather than after seeing a five-minute demo.

That last part is particularly important. People are often good at describing what they think they will do. Actual usage tells us what they actually do. Internal tools let us observe the difference.

§The danger of building only for yourself

There is, however, a trap. If we only build for ourselves, we can become too attached to our own assumptions.

Our workflow may not be normal. Our technical knowledge may be unusual. Our tolerance for complexity may be much higher than that of an ordinary user.

An engineer might happily configure something through a terminal because they understand what is happening. A non-technical user may reasonably expect a button.

So once an internal tool shows promise, the next step is not simply to expose it publicly. It is to question our assumptions.

This is where an internal tool begins its transition into a product.

§From internal tool to product

We think about this transition as a series of stages.

The process is not always linear. Sometimes we go backward. Sometimes a problem turns out to be smaller than expected. Sometimes the product changes completely. That is part of the process.

§Prudentum

Prudentum is an example of the kind of problem we are interested in.

Personal finance can look simple from the outside. Record an expense. Record income. Look at the balance.

But once we started thinking about the experience more seriously, the problem became much larger.

These questions emerged because we were trying to build something useful, not because we were trying to fill a feature checklist. The product keeps teaching us what the product needs to be.

§StuQuo

Education software has a similar pattern. Learning platforms often become collections of features: courses, lessons, tests, certificates, discussions, resources, analytics.

But the underlying problem is not a list of features. It is infrastructure.

Those questions are what led us toward thinking about StuQuo as modular education infrastructure rather than simply another LMS. The product direction emerged from the problem.

§TouchTrack

Attendance is another example. At first glance, attendance seems like a simple record: a student is either present or absent.

But the actual problem is more complicated.

How do we know the student is physically present? How do we prevent proxy attendance? How should teachers start an attendance session? How can students verify themselves quickly? How do we make the entire process less disruptive?

The interesting part is not the attendance table. It is everything required to make attendance reliable without making the classroom experience worse. Again, the problem leads the product.

§What survives is what gets used

One of the simplest rules we can follow is also one of the hardest: keep the things people actually use.

It is easy to become emotionally attached to a feature because we spent time building it. But engineering effort is not evidence of product value.

A feature does not become valuable because it took three weeks to implement. A feature becomes valuable when it solves something meaningful.

This mindset makes it easier to remove things. If something is not useful, we should be willing to delete it. If a simpler workflow works better, we should choose the simpler workflow. If the original idea was wrong, we should change the idea.

The code is not the product. The problem being solved is the product.

§Building is a form of research

This is perhaps the broader idea behind all of this. When we build an internal tool, we are not only producing software. We are conducting an experiment.

In this sense, engineering and product discovery become closely connected. Writing code is one way of asking a question. Using the resulting software is one way of getting an answer.

§Small tools can reveal large problems

Sometimes the original tool is much smaller than the problem it exposes.

You build a small utility to solve one annoying task. Then you realize the task is only one symptom of a larger workflow problem. You solve that. Then another problem becomes visible. Eventually, you may discover that what looked like a tiny inconvenience is actually an entire category of unmet need.

This is where internal tools become interesting. Not because they automatically become products, but because they can act as probes into real workflows. They help us see problems from the inside.

§We would rather discover than predict

There are two ways to approach product building. One is to spend a long time trying to predict what people will want. The other is to build small things and learn from what happens.

Neither approach eliminates uncertainty. But the second gives us a way to reduce it.

That is what we like about internal tools. They turn speculation into interaction. Instead of asking would someone use this?, we can sometimes get to we are using this, and here's what works. That is a much better starting point.

§The Sarezo approach

This is becoming one of the principles behind how we think about Sarezo.

We don't want to begin every project with what SaaS product should we build? We want to begin with what problem keeps getting in the way?

The important part is the order.

Problem before product. Use before assumptions. Learning before scale. Validation before launch.

§Build something you need

There is something satisfying about software built this way. You don't begin with a pitch deck. You begin with irritation.

Something doesn't work the way you want. So you fix it. Then someone else encounters the same problem. You show them what you built. They use it. They tell you what is wrong. You change it.

Eventually, something that began as a tiny internal tool becomes useful to people you never expected to build for. That is the kind of product journey we are interested in.

Not because every internal tool becomes a company. Most won't. But because the ones that do have something valuable behind them: they started with a problem that someone genuinely wanted solved.

And that is usually a better place to begin than with a product idea.