Guide

Custom software: examples from practice

How custom software is actually used in the everyday life of small businesses — real workflows instead of product promises, including the cases where it didn't work.

Quote on requestfrom 8 weeks to first versionAs of 2026
In short

In practice, custom software almost always starts with exactly one workflow, not with an overall concept. The most expensive software projects are those where nobody could use anything for twelve months. Expansion happens only when the first step has demonstrably worked in real operations.

01 — Practice

What this looks like in concrete terms

Observation from practice

The most expensive software projects are those where nobody could use anything for twelve months.

A typical entry point looks like this: The business identifies the one workflow that causes the most disruption. We observe how work is done today. This regularly uncovers requirements that nobody would have mentioned.

After going live, we don't expand immediately — we observe. Documentation, training, source code. You shouldn't be tied to us.

02 — Fit

When it's worth it

  • The process in question occurs at least weekly.
  • It follows rules you can write down — even if there are exceptions.
  • Today it's manual work that no one enjoys doing.
  • There's one person who decides, not three who need to coordinate.
  • You can name what would tell you it worked.

03 — Scope

When we advise against it

  • The process is still changing. As long as you're adjusting the process itself, manual work is more flexible and cheaper.
  • Exceptions outweigh standard cases. Then you're automating exceptions, and that gets expensive.
  • There's no data foundation. Without digitally available source data, the basis is missing.
  • Volume is too low. With five transactions a month, no system pays off — not even an affordable one.
  • The real bottleneck lies elsewhere. If you don't have enough inquiries, you don't need faster processing.

04 — Questions

Frequently asked questions

When does custom software pay off compared to standard software?

When your process is a genuine competitive advantage, when standard software only fits seventy percent and the rest ends up as manual work, or when license costs per user exceed the development cost over a few years. If it's only about convenience, standard software is cheaper.

How many users can a system like this handle?

That depends on the architecture, which we plan according to your expected growth — from a few users in your own business to several hundred across multiple locations.

What if we discover new requirements during development?

That's normal and planned for, because we work in small steps. A new requirement is incorporated into the next step, instead of stalling the entire project.

Can we start with a spreadsheet?

Often yes, and that's a good test. If the spreadsheet maps the process and only fails due to multi-user capability, permissions, or data volume, the requirement is clear and the project is calculable.

Does this run on our own servers or in the cloud?

Both are possible. For most businesses, a cloud solution is lower-maintenance; where data must not leave the premises, we set it up on your own infrastructure.

How do we avoid the project going off the rails?

Small steps with usable results, fixed budgets per step, and the option to exit after each step. Large fixed-price projects over twelve months are the most reliable path to disappointment — for both sides.

What happens if we no longer work together?

You have the code, documentation, and access. We deliberately use widespread technologies so that a switch is possible without someone having to rebuild everything.

Next step

We'll look at your starting position.

Tell us what's eating up time today. That becomes an assessment with effort and benefit — and only then an offer.