When does a business outgrow manual work?
Access sent by hand after each payment, bookings kept in a spreadsheet, invoicing in the evening — it works up to a point. This page explains where that point is, and what comes after it.
- Written by
- Kristóf Karner — independent developer, Budapest
- Updated
- 22 July 2026
Most businesses start with manual work: an email arrives about each payment, someone sends the access or the confirmation, the invoice gets written in the evening, the bookings live in a spreadsheet. Up to a few dozen customers this works, at a few hundred it does not: every step waits for a person, and there is one person.
In this article I describe the signs that manual work has reached its limit, what is worth automating at that point and what is not — and how such a system gets built.
What are the signs that manual work is at its limit?
The limit is not a single moment but a series of symptoms. These are the most common ones, the way they show up in everyday work:
- You type the same data two or three times into different places — from the payment into the spreadsheet, from the spreadsheet into the invoicing tool.
- The customer asks about the email before you could have answered it.
- Hours pass between the payment and the start of the service, because the step is waiting for you.
- Part of the evenings and weekends goes to administration.
- During a holiday the process stands still, or limps along from a phone.
Any one symptom on its own is manageable. When several become regular, the process takes more attention than the work the revenue comes from.
What can be automated?
Automation rarely means new software. Mostly it means connecting the tools already in use — the payment provider, the calendar, the invoicing service, the messaging app — so that data moves from one to the next on its own, without a person. A few typical connections:
- Payment → access: after a successful payment, the buyer receives what they bought on its own — a login, content, group membership.
- Payment → invoice: the invoice is created and sent the moment the payment lands; there is nothing left to type in the evening.
- Booking → confirmation → calendar: the guest books for themselves, the confirmation goes out immediately, the calendar updates itself.
- Form → notification: the enquiry arrives where you actually read — email, Telegram —, with the important data highlighted.
By hand
- Payment arrives a notification email comes
- Finding the email when you have time
- Sending the access by hand, one by one
- Writing the invoice in the evening, with the rest
With a system
- Payment arrives the system notices it
- The system acts access · invoice · notification
- Done seconds later, at night too
What is not worth automating?
Not every process belongs on a system. What you do a few times a month, and it takes minutes, is cheaper by hand — building pays off where the step repeats daily or weekly. And what needs a real human decision — a custom quote, judging exceptions, handling complaints — is not something to automate but to build around: the system takes away the administration, the decision stays with the person.
How does such a system get built?
Building starts with describing the process, not with writing code. First we record how it runs today: who does what, when, after what — that shows where the process waits for a person. Then comes building the connection, and then the test: the system first runs in trial mode, without live money and live customers, and only takes over the work once it has proven itself.
After going live, the system operates — and that is the part that ties system building to maintenance. The environment it runs in changes: providers update, the process grows. A separate page covers that work.
How dependent will you be?
This question is worth asking at the start, because a system serves for years, and circumstances can change along the way. With me it looks like this: the accounts and the access — hosting, payment provider, invoicing service — are in the client's name; I work in them, I do not own them. The system gets a write-up: what runs, where, and what does what. If someone else takes over one day, there is something to hand over.
If there is a process in your business that keeps waiting for you — the steps after a payment, bookings, invoicing —, send an email and describe how it runs today. I will write down what could be put on a system, and what is not worth it. One exchange of letters usually shows whether there is anything to do here.
kristof@kristofkarner.comFrom here on, this is what the work looks like in practice. Everything needed for a decision is above — this part is for those interested in the details.
How I do it in practice
I fit into the existing tools, not the other way round. The most common building blocks with me are Stripe for payments, Telegram for messaging and Számlázz.hu for Hungarian invoicing — but the starting point is always what the business already uses, because switching tools is a cost in itself. I build the connections through the providers' official interfaces, not through workarounds — that lasts longer, and it does not break on updates.
Testing gets particular attention, because in a payment flow a fault is not a theoretical question: someone's money and someone's access depend on it. The system therefore starts in trial mode, rare cases included — what happens when a payment is interrupted, when someone pays twice, when a card expires.
What does this look like live? Among my projects, the case study about building automatic access from payments is the closest to this page: it shows the full path of a subscription system, from the payment to withdrawing access.
Questions on this topic
Do I need programming knowledge on my side?
No. Your part is to describe how the process runs today — who does what, when, after what. Building and maintaining it is my work, and the finished system runs on its own; you do not have to touch it.
Can it be added to an existing website?
In most cases, yes. The system is typically built alongside the website, not instead of it: the existing site stays, and gains a layer that carries the process — payments, bookings, notifications.
What happens if it breaks?
The system sends an alert when a step fails to run, and I fix the fault. That is why maintenance belongs with system building: the environment a running system lives in keeps changing, and someone has to follow it.
What tools do you work with?
I fit into the tools the business already uses. The most common ones with me are Stripe for payments, Telegram for messaging and Számlázz.hu for Hungarian invoicing — but the starting point is always what you already use.
How long does it take to build such a system?
It depends on the complexity of the process: a simple connection is measured in days, a multi-step system in weeks. After the assessment this can be stated precisely, and the estimate stays in writing.