Notes · For the Owner

How a Small Business Can Find a Reliable Developer Without Spending All Its Money on One

Oleksandr Antonenko · Vilnius · 28 October 2026

When a small business owner looks for a developer for the first time, they usually ask around among friends, read reviews on freelance marketplaces and hope that someone reliable turns up. I am a developer and a business owner myself, so I see this search from both sides. Below is what I would tell a friend who is about to pay someone for software for their business.

The main thing I want from a project like this is for the first version to start earning or saving money as early as possible. Then the next steps are paid for out of that money, and the owner isn't risking everything at once.

What reviews actually tell you

A review confirms one thing: the person delivered something, and the client was happy at the moment of delivery. It doesn't tell you whether the software still works a year later or whether the business has made a single cent from it.

It happens that a system is built neatly, delivered on time and praised in a review, and six months later the office is back to working in an Excel spreadsheet. Nobody writes that in a review.

So for me a vetted developer is someone whose work I can check for myself, not someone with a lot of stars.

What to check before the first payment

• Ask to see a working system you can open and click through. If the project is under NDA, a decent developer will show it on demo data.
• Ask what changed for the owner of that system in money and time. "Built it in React" tells you nothing. "A report that used to take seven working days is now ready in two hours" tells you everything.
• Talk to that owner. One short question: are you still using the software.
• Listen to what the developer talks to you about. If it's your orders, stock, payments and people, that's a good sign. If it's frameworks and architecture, they haven't understood your business yet.
• Get a written plan before you pay: what will be done, in what order, how long it will take and how much it will cost. Said out loud, all of this sounds convincing and is forgotten within a week.

If the developer expects a written spec from you

A classic developer is good at building what a technical specification says. That is honest work, and there is nothing wrong with it. The problem is that someone has to write the spec, and write it in technical language.

If the developer you found expects a finished spec, first find a business consultant who will work through your processes and translate them into the developer's language. Otherwise you will write the task the way you understand it, the developer will build it the way they understood it, and there is a real chance of ending up with work nobody needs.

Start with one place where money leaks every week

A common mistake of an owner ordering development for the first time is to order everything at once: a website, a CRM, inventory, a mobile app, bank integrations. A big project takes a long time to build, brings nothing for a long time and eats up the budget before anyone has used it.

I suggest something else. Find one place where the business loses money or hours every week. It is usually in plain sight:

• orders from a messenger are retyped into a spreadsheet, then once more into the courier's system;
• payments are reconciled by hand against the bank statement;
• the report for the manager or the client gets written in the evenings;
• stock levels are checked by phone call, because the spreadsheet doesn't match the shelf.

Build the first version for exactly that place. It is small, so it is ready quickly and starts saving quickly. Those savings pay for the second step, and so on. The steps add up to a system where the whole path of an order lives in one place.

Here is what that looks like in an example from my own practice. A hair care brand makes its own product, and I built them a system where everything holds together. When a batch is produced, raw materials are written off according to the recipe and the cost price is calculated right away. Goods sit in several warehouses: the central one, regional ones and the salon. An order from a retail customer or a partner salon reserves stock in a specific warehouse, then come delivery, payment and the month's profit. Production, stock, customer, order and money in one system, and nobody retypes anything between programs.

Put a price on the problem before you talk to a developer

Before the first meeting, sit down with a calculator and work out what your problem costs you per month:

• people's hours spent on manual work × the cost of their hour;
• lost or mixed-up orders × your margin;
• penalties, returns, repeat deliveries;
• the subscription to a service you pay for but which doesn't fit you.

You will get a number. The first step of development should cost less than this problem costs over a few months. If the developer proposes something more expensive, either the step is too big or they haven't heard where it hurts.

With this number, the conversation with a developer becomes a completely different one. You already know what you are buying and how soon it pays back.

Own everything from the first minute

This is the most important point, and the one most often forgotten. Business owners regularly end up hostage to their developer. The code sits with the developer, the server is registered to the developer, so is the domain. When the developer doesn't like something, they simply stop picking up the phone, and the business stands still.

To keep that from happening, from day one:

• the GitHub repository belongs to you, and you invite the developer into it;
• the server, the domain and all services are registered to your email and your card;
• in the work chats you are the admin, not the developer.

This is not a question of trust. A good developer will suggest it themselves, because it is easier for them too when the lines of responsibility are clear.

Demand documentation from day one

Every task and every decision has to be written down: what was done, why it was done that way, how to run it and where things are. Without documentation, replacing the developer is practically impossible, and you are a hostage again.

In the age of AI this is no longer a burden for the developer. If you ask the AI to record the course of the work and the decisions, documentation appears almost by itself. So the answer "we'll write the documentation later" is not acceptable today.

Someone from outside should keep an eye on the process

One more piece of advice that saves a lot of money: find a professional who will spend an hour a week looking at how the development is going. They read what has been done, check it against the plan and tell you in plain words whether the project is moving or standing still.

Outside oversight keeps developers within bounds. When a developer knows a peer reviews their work once a week, they don't drag things out or idle at the client's expense. For you it is cheap insurance against the most expensive scenario, where six months in it turns out the wrong thing was built.

How I work

I am a developer and a business owner, so with a business owner I talk about orders, stock and money, and I write the development plan myself. There is no need for a separate consultant to write a spec with me: I work through the process together with the owner and translate it into technical decisions myself.

I take the system on in full: database, server, website, mobile app, launch and supervision after launch. I am personally responsible for the result. For narrow tasks I bring in experienced specialists I have already worked with on previous projects.

Among my work is LilyAssist, an assistant that writes reports for school psychologists: a report that used to take seven working days is now ready in about two hours. Curl School is a course platform for hairdressers where enrolment, payment, access to materials and the certificate all happen without the office being involved. There are thirteen projects on the home page of this site.

We start with a short conversation. After it I send a written reply: what I would do as the first step, how long it would take and how much it would cost. You make your decision with that document in hand.

In short