Software for the way
you work

Yes. A small system is still a system, and I treat it exactly like a large one — it is not a favour and not a warm-up for something bigger.

Typically it looks like this: one process, sometimes two. A handful of screens instead of a dozen. A few or a dozen-odd people working in the system. A timescale measured in weeks, not months. And you still get your own system built from scratch for your company — not a plugin, not a script, not a bolt-on to somebody else's program. The scope changes, the way of working does not.

The criterion is not the size of the company or the size of the job, but whether the process can be described: who does what, in what order, what should come out of it and what breaks today. If you can tell me that in your own words, there is something to build a system from — and that is enough to start a conversation.

Larger rollouts I take on as well: several processes, more roles, a move off an existing system. Those run stage by stage and take longer than a few weeks, but they start the same way — with one process that works from end to end. And if, after we talk, I conclude that an off-the-shelf program is all you need, I will say so plainly rather than sell you a project.

One process you can describe in your own words. Who does what, in what order, what should come out of it and where it gets stuck today — that is the whole starting point I need. You do not need a specification, a ready-made idea for the system, or an IT department of your own.

Beyond that, two things: about 2–3 hours of your time a week while we build, and one person with the authority to say “yes, that is how it works”. I build for companies where decisions are made quickly and there is someone to sign off the next stage — usually the owner or a manager who knows the process from the inside.

If the process is still taking shape and looks different on every job, let's start with a call: an hour is often enough to see which part can already be described and built, and which part is better sorted out inside the company first. That call is free and you do not have to order anything after it.

It does not have to, and usually it should not. Your accounting software — Comarch Optima, Subiekt GT, enova or another — stays where it is and keeps doing what it was made for: invoices, stock, the books. What I add alongside it is the layer it does not have: your sales, job or service process, with the stages and fields that actually occur at your company.

The two parts see each other. The data that has to reach accounting — the customer, the order, the basis for an invoice — I pass through to where it belongs, so nobody retypes it a second time by hand. The scope of that exchange is agreed before we start, based on what your software can make available.

The same principle applies where the law requires certified software — medical records, for instance. The records stay in the program meant for them, and I build what happens around them: the schedule, consent flows, job orders, notifications.

Five things, in a few sentences — I do not need a specification or a ready-made idea for the system. First: which process hurts most and where exactly it gets stuck. Second: how many people will work in the system and in what roles. Third: what software and tools you use today — spreadsheets, email, chat, Comarch Optima, Subiekt GT, enova. Fourth: what you would like to automate or stop retyping by hand. Fifth: whether data has to be moved from an old system or from spreadsheets.

If you do not know something, write “I do not know” — that is information too, and nobody will hold it against you. I usually reply within one business day: either I ask about what is missing, or I propose a free call straight away. You get the quote in writing, with the scope and the date spelled out — before the work starts.

And you do not need a year. Stage 1 is one process from end to end — for example the path from an enquiry to a sent quote, or from a job order to a signed handover report. A closed scope, 3–6 weeks of build time, and at the end your team has something it actually uses. Add 1–2 weeks for the process map before the start and 1–2 weeks for data migration and training after handover, so from the first call to working live it is usually 6–10 weeks.

A smaller scope — one process, a handful of screens, a few people working in the system — sits at the lower end of that range and sometimes below it. Often that is also where it ends: there is no second stage, because there is nothing left to add. Large rollouts do take longer and run stage by stage, but that is one possible scenario, not the default one.

I do not start by building everything at once, because that is exactly what most rollouts look like before the system gets abandoned. On your side I need about 2–3 hours a week and one person with the authority to say “yes, that is how it works”.

The repository sits on your company's account from day one — the files never live with me, so there is no “handover of the code” moment. Economic rights to the code pass to the company once the given stage is paid for, and this is written into the contract; from then on you can do anything with the code, including handing it to another developer, without asking me.

The repository also holds instructions for running the project from scratch and a description of the data model. If you ever decide to move to someone else, you get a complete package, not a puzzle.

The database and hosting belong to your company, and the data stays in Poland or the European Union. I have working access that you can revoke with a single decision, without asking me. As standard from the first version: roles and permissions (a sales rep does not see margins if they are not supposed to), an event log showing who changed what and when, and backups with a tested restore — because a backup nobody has ever restored is not a backup.

On top of that: encrypted transmission and a data processing agreement. With a subscription product you get the log to the extent the vendor makes it available; here you get all of it.

I do not have any and I will not paste in invented ones. Instead of social proof I offer three kinds of proof you can check yourself, before you sign anything.

First: a free technical call in which I sketch out your process and data model — anyone who cannot understand your process in a single call will not build a system for it. Ask me anything on that call: about the database, about integrations, about what happens when you change your mind halfway through. You will come out of it knowing more about your own process than you did going in, even if you order nothing. Second: the screen mock-up on the home page. It does not pretend to be more than it is — it runs on invented data, it is labelled as such, and it is not proof of a rollout. It shows the layout of the screens and how such a system splits the work into stages, so you can picture the product before we even talk. Third, and most important: a small, paid first stage as a test of working together — you check me on real work with a closed scope before you decide on anything bigger. The repository sits on your company account from day one, so if you conclude after that stage that this is not working, we stop and the code stays with you.

That is a real risk and I am not going to pretend otherwise. What can be done is to bring it down from “someone has to write the system from scratch” to “someone has to find another developer”. So: the repository is on the company account from day one, the system runs on your infrastructure and your accounts, and I build on a standard, widely used stack — TypeScript, Next.js, Node.js, PostgreSQL — with no in-house inventions that nobody but me knows, and the repository holds setup instructions and a description of the database.

The effect: if I am gone, you lose me, not the tool. On larger projects we can additionally arrange source code escrow with an external agent.

Sometimes an off-the-shelf program is all you need — and I will tell you so rather than sell you a project that will not pay for itself. The dividing line, though, does not run where it is usually drawn. It is not about whether the company is small or large, but about how far your process departs from what an off-the-shelf program assumes in advance. A typical sales pipeline and nothing beyond it? Take the subscription — it is cheaper and faster, and you will hear that from me on the first call, not after signing a contract.

When the process does depart, the arithmetic looks different — with a small team too. A small system built around one specific process can cost less than a subscription that still needs setup and configuration paid on top, and then work-arounds for everything the program cannot do. Ask your vendor to quote setup and configuration before you compare prices; it is the part of the bill you do not see on the pricing page. Add the fee for every further person — including the warehouse keeper and the bookkeeper who open the system once a day — and, if the team works alongside the system anyway, in spreadsheets, you are paying twice.

This is not a choice between cheaper and more expensive, but a choice of the kind of cost you take on: a one-off investment and low, predictable upkeep instead of a fee that grows with every person and every year. There is one quote and it is prepared for your process — I do not bid against anyone for the lowest number in a table. Let's do the maths on your numbers before you order anything: even if the answer turns out to be “stay with what you have”, you will know that before signing anything.

Yes, that is a standard part of stage 1. I move contacts, job history, quotes and files — from an export out of the previous system, from its database, or straight from a spreadsheet. We usually do it twice: once as a trial run, so you can see how the data looks after the move and what needs tidying up, and once for real at go-live.

An honest caveat: if the data is a mess at the source — three spellings of the same company name, missing tax numbers — no migration will fix that for you. I will tell you plainly what can be moved automatically and what someone has to review by hand.

It will change, for certain — which is exactly why the system is yours. Small changes — a new field, a different order of stages, a different quote template — I handle within the care package: no contract annex and no three-day estimate, within the hours assigned to the package. Larger changes are quoted separately, before the work starts.

There are no fees for an extra user, an extra field or a “module”, so growing the company does not raise the bill automatically. Nor is there a situation where a vendor retires your plan or changes the price list and presents you with a done deal. And because the code is on your account, a bigger change can be made by anyone — it does not have to be me.

I run a sole proprietorship and issue an invoice for every stage — the company details and registration numbers are on the “Company details” page. Payment is split: part at the start of a stage, the rest on acceptance of the working scope, with dates and amounts in the contract before the work starts. There is no “whatever it comes to” billing — a stage has a fixed price agreed up front.

Costs you pay directly and that do not go through me (hosting, domain, SMS gateway, transactional email) are listed separately and I add no margin to them. If you are financing the rollout from a grant, I will prepare the scope description and schedule in a form that can be settled.

We settle for the work done up to the notice date, based on the change history in the repository. The code that has been created and paid for stays with you, together with the economic rights — you do not need my consent for that. There are no penalties for withdrawing and no contract that locks you in for a year.