Understand the operation.
Working in operations taught me that the brake is rarely where it first appears, so I start with the e-mails, payments, channels and people, and only then decide what to build.
For owners and operations leads whose people still retype data, chase payments, bookings or deadlines, and bridge tools that do not talk to each other.
Web applications, native iOS apps and backends delivered from design through development to deployment – with no handover between an analyst, an agency and a developer.
Five moments where the current setup stops being enough.
No attack on any particular tool, just a description of the situation.
Enquiries land in e-mail, orders get retyped, payments are watched on the side. The site only presents; it does no work for you.
E-mail, Booking.com, phone, a calendar kept by hand. Something falls through, and you cannot say exactly where.
Matching in a spreadsheet, retyping into the accounting system, chasing differences, surcharges and cancellations. Hours a week disappear into work a system should be watching.
Exports to spreadsheets, workarounds, the same records kept twice. The software was supposed to save time; every month it takes more.
Official deadlines, dates and confirmations do not wait until you reach a laptop. On the road you work blind from your phone and hope nothing important slips.
The same approach for a booking system, a tax SaaS and a native iOS app.
The technology changes, the way of working does not.
Working in operations taught me that the brake is rarely where it first appears, so I start with the e-mails, payments, channels and people, and only then decide what to build.
Sometimes custom software. Sometimes an integration. Sometimes a better off-the-shelf tool. The goal is not to build at any cost, it is a calm operation. When an existing tool is enough, I say so.
The result is not a document or a proposal. It is a working site, app or system that takes over a specific part of the work, is tested against real situations and can be operated afterwards.
Three publicly available systems. For each one I separate what is publicly verifiable from impact that would need measurement and the client’s permission.
App Store name: Freelax - Data Box Client
The data box as a work queue. Priorities, tasks and decisive data on the phone.
A native iOS client built from the ISDS layer through priorities and a local archive up to widgets and biometric unlocking.



The Czech data box has a statutory delivery regime. Signing in as an authorised person can trigger delivery, and without signing in delivery can occur by legal fiction, so the app must never present an indicative notification as the decisive state in ISDS.
The app separates the e-mail signal from a live ISDS fetch and gives the user a working overview of priorities, attachments and items to handle.
An e-mail notification does not itself cause delivery. The decisive delivery data and deadlines stay in ISDS and in the original document; the app uses them as a basis for work, not as a replacement for the official source.
An example of a system where operational simplicity rests on correctly designed boundaries, privacy and handling of exceptions.
Control over the tax year for freelancers and expats.
Czech freelancers often deal with income tax, insurance, the VAT threshold and annual statements only in hindsight. Expats add the language barrier and the Czech rules on top of that.
A year-round overview built from real income, supported by a documented method and a public knowledge base in Czech and English.
The production SaaS at freelax.cz shows the running trajectory of the year and explains which rules and inputs it is based on.
An example of a long-running product that combines domain rules, payments, content and user accounts.
A static website became an owned booking channel.
Bookings, availability, payments, confirmations and calendars were handled through e-mails, Booking.com and spreadsheets.
I designed and delivered the website, the booking flow and the operational administration, with Booking.com synchronisation, confirmations and protection against double booking enforced by the database.
Today there is a publicly verifiable booking channel of their own and a production operating system. I do not publish a quantified business impact without measurement and the client’s permission.
The closest example of client work where one supplier connected the customer-facing site, payments, integrations and everyday administration.
The payment flow through GoPay, including the refund on cancellation, is built and covered by unit tests: the dates are held briefly while payment runs and the payment is confirmed independently in three places, by the gateway notification, by the guest returning to the site and by a background check. The gateway is still waiting to be activated, so bookings are completed by phone or e-mail today.
For small changes with no operational impact I am probably not the best choice.
It is fairer to say so now than after two weeks of meetings.
We start by e-mail. When the operation has to be untangled first, we continue with an operations diagnosis. Once the scope is agreed you know what you get, when it will be ready and what it costs. No creeping increases, no open-ended hourly meter.
I am not a VAT payer. The prices shown are final.
You feel a brake in the operation but do not know whether to buy a ready-made tool, connect the systems you already have, automate manual work, or have something custom built. We go through the operation together and you get a clear recommendation. Sometimes the outcome is a recommendation to use an existing tool, and that is where it ends.
If we continue with delivery within 30 days, I deduct 50 % of the diagnosis price from the first invoice.
You have one specific process or customer step that you want running in production without a large build.
Outside defect fixing: New features, changes of brief, third-party service outages and long-term operational care are handled separately.
Example of a possible scope: booking → payment → confirmation and access for one site; enquiry → check → handover; or one verified data flow between existing services.
I do not build brochure sites or template websites. Every delivery contains concrete operational logic or an integration.
You need a complete system with several roles, states or integrations. It works with history, exceptions or data migration and is used by several people or parts of the company.
Outside defect fixing: New features, changes of brief, third-party service outages and long-term operational care are handled separately.
I do not start a larger brief with a nine-month commitment. First we pick the part that can work on its own and price it as a phase of its own.
Every phase ends in a deployed result that can be handed over.
The contract sets in advance which bespoke code, documentation, accounts, data and third-party licence boundaries are handed over.
If a project needs a parallel team, several specialisations or platforms, an enterprise regime or round-the-clock support, I say so immediately and recommend a team or an agency as the safer form of delivery.
Send your problem for reviewYou are using a system I delivered and you optionally want to agree operations, updates and problem solving in advance.
Condition: The entry minimum applies only to a system I delivered.
Operational care is not mandatory. The system can be handed over and individual work ordered as needed. New features, larger changes, hosting, domains, licences and paid APIs are outside the monthly fee. Taking over somebody else’s system is not part of the entry package.
The first e-mail is free and without obligation. I will say whether the problem is worth solving, what I still need to know and what the next step should be. The concrete scope and price are confirmed once I understand the situation well enough.
Send your problem for reviewI do not start with technology. I start with how the work actually runs: who retypes what, where the errors appear, what is checked by hand and where the time goes.
Experience with operations, logistics and customer service in London taught me to look at the real work first and at technology second.
Today I build my own products and client projects across web, iOS and backend. I sell the result, not technologies or hours; the scope of the handover of code, documentation, accounts and data is agreed in the contract in advance.
If your question is not here, write to me. I answer directly in e-mail, or we set up a call about it.
Because on projects like these you are buying a result, not time at a keyboard. First we bound the problem, the risks and the expected output. Then you get a price for a specific step, with no unpredictable hourly meter.
The first e-mail is free and without obligation. Describe in your own words what slows you down today. Within 48 hours I will tell you whether the problem fits, what information I am missing and what I recommend as the next step. A call comes once we both have something to talk about.
I build where it makes sense for your situation. The public portfolio covers production web systems and a native iOS app. I choose the technology after the problem, the operation and the people who will use the result.
No. Your job is to describe the operational problem in your own words. My job is to turn it into a scope you can follow, name the risks and propose something that can be run safely.
Yes. Written communication, documentation and calls work in English or Czech. The binding privacy notice and the contract framework are published in Czech on the Czech version of this site; the English wording here is there so the offer is clear before we start.
It depends on the scope. One thing in production takes typically 4–7 weeks · fixed scope. A new custom system takes typically 6–12 weeks · payment by milestones. A larger brief is first split into an independently usable phase with its own price and date. The concrete scope and price are confirmed once I understand the situation well enough.
Delivery projects are followed by 30 days from production launch to fix reproducible defects against the agreed scope. New features, changes of brief, third-party service outages and long-term operational care are handled separately. After that I either hand the system over and you order further work as needed, or we optionally agree operational care. On larger briefs, every phase ends in a deployed result that can be handed over. The contract sets in advance which bespoke code, documentation, accounts, data and third-party licence boundaries are handed over.
If the brief changes, I say so immediately. I hold the agreed scope. When we hit a larger change, we stop, name the effect on price and date, and you decide whether to continue.
You do not need a technical brief. A short description is enough: what you handle manually today, where the errors appear and what it costs you in time or money. The first e-mail is free and without obligation. Within 48 hours I will tell you whether the problem fits, what information I am missing and what I recommend as the next step.