Home / Custom software

Custom software

Most companies do not need a new system. They need the one they already run to finally do its job. Custom software makes sense where an off-the-shelf tool forces you to bend the company around the program instead of the other way round.

Custom software is a program written for one specific company around its own rules — unlike off-the-shelf software, where the company adapts to the program. It pays off where you have a process that gives you an edge, or where modifying a ready-made system would cost more than building your own.

It does not pay off for ordinary admin. Do not write your own accounting, payroll or e-mail — buy those and connect them to the rest of the company instead.

When it pays off and when it does not

Worth buildingNot worth building
You run a process differently from your competitorsOrdinary admin — accounting, payroll, e-mail
An off-the-shelf system would need heavy modificationA ready-made tool already fits 90% of the need
Per-user licences grow faster than the investmentYou have a handful of users and simple admin
Data gets retyped by hand between three placesYou do not yet know what the process should look like
You need to own the data and have it at handThe main criterion is the lowest possible price

What usually gets built

  • Internal systems — orders, warehouse and dispatch, job tracking, attendance
  • Integrations — so the e-shop, warehouse and accounting pass data to each other
  • Automation — work someone does by hand every single day
  • Reports and dashboards — numbers you currently wait for until month end
  • Work on what already runs — adding the features your current software is missing

An approach that does not end in a half-finished system

Most failed projects die because six months go into building the “big solution” and only at the end does it become clear what should have been done differently. The reverse order works better.

  1. Find the most expensive annoyance. Not the most visible one — the one that costs the most time and mistakes.
  2. Solve it on its own. A small working piece people start using within two weeks.
  3. Let real use do the talking. After a few weeks it is obvious what comes next — and it is usually not what the original plan said.
  4. Add piece by piece. Each one builds on what already proved itself.

There is a financial upside too: you can stop at any point. You are not left with a half-built system, but with several things that work.

What to check when picking a supplier

  • Who owns the code. Ask outright. The repository, servers and access should belong to you, not the supplier.
  • Who will actually write it. Agencies often hand the work down to juniors. Ask for a name.
  • What happens after delivery. Software without maintenance ages. Find out what running it costs and how fast an outage gets fixed.
  • Whether you can start small. A supplier who demands a six-figure analysis first is shifting the risk onto you.
  • What it runs on. Exotic technology means nobody will take it over from them in three years.

How I work

I am one person, not an agency. There is no team of juniors the work gets passed down to and no subcontractor in another time zone — which is why I take a limited number of companies at a time. I work on a flat monthly rate rather than by the hour, so there is no estimate to inflate.

Most often I build web applications in JavaScript and TypeScript over a PostgreSQL database, deployed on Cloudflare or Vercel. If you already run something, I build on it instead of rewriting it.

I am based in Czechia and work in English as well as Czech.

Frequently asked questions

A program written for one specific company around its own rules and processes. Unlike off-the-shelf software, where the company adapts to the program, here the program adapts to the company.

The first usable piece is normally ready within two to four weeks, provided you start from one concrete thing. A full company system gets built piece by piece over months, but you use it as it goes rather than waiting until the end.

You do. The code repository, the servers and all access should belong to the client. If the supplier keeps the code, you depend on them and lose everything when the relationship ends.

No. Most companies arrive with a description of what slows them down, not a technical spec. The spec comes out of the conversation — and tends to be better than one written at a desk beforehand.

Yes, and it is the most common request. Integration works over an API, through import and export, or directly into the database. Missing features can be added without abandoning your current system.

Related

Got something concrete that slows you down?

Fifteen minutes is enough to work out whether it can be solved and where to start.

Pick a time