TransHans
A bus carrier's own ticket booking app
System ArchitectureProduct ConceptUX/UICustom SoftwareIT Consulting
For founders and business owners with something specific to build: a product, a portal, or an integration nobody else will take on. We agree on what the first version needs to do, build it, and continue developing it afterwards. The same team stays with you in year one and year three.
You pay a fee on every transaction, while the platform controls the customer relationship. You cannot change the pricing, rules or checkout without asking permission first.
Orders arrive by phone, email and online forms. Someone copies them into a spreadsheet, and by Friday two people are working with different numbers.
Payments, e-invoicing, fleet tracking, or a legacy system whose API documentation no longer matches reality. This is often the piece that determines whether the rest is worth building.
We start with what needs to change in the business, not with screens. Then we define the smallest first version worth putting into use and build it.
A rough idea becomes a document you can approve: what the first version will do, what it will leave out, and what can wait until later.
The system has to work with what you already use: payments, e-invoicing, GPS, or an internal database nobody has touched in years. We assess this part first because it often determines the timeline.
The repository, environments and documentation are yours from the first week. If you ever move the system to another team, there is nothing to buy back.
Both models are valid, but their costs and expectations differ. Most projects start with a fixed scope and move to ongoing development once the system begins to generate value. Problems arise when someone pays for one model but expects the other.
| A fixed scope | Ongoing development | |
|---|---|---|
| What you are paying for | A defined piece of work with a finish line | Capacity to keep changing the system while the business changes |
| How we agree it | Written down before the build starts | Reviewed every few months against how the system is actually being used |
| When to pick it | The need is clear and the business around it is steady | The process keeps moving: new channels, new rules, new markets |
| What it costs | One budget, known before anyone starts | A build, and then a smaller running cost |
| Who owns it afterwards | You do, whether or not we continue working together | You do, and we are available when it matters |
| The honest risk | Anything you think of later is a new scope | You pay for a team you may not need every month |
TransHans is a bus carrier. Every ticket sold through a booking platform incurred a commission, and the platform owned the customer relationship. We built the company its own booking app, integrated with KSeF e-invoicing and vehicle GPS, and have continued developing it since 2022.
A bus carrier's own ticket booking app
We have connected SAP in real time to warehouse scanners and DHL, bringing delivery scheduling, invoicing and warehouse operations into one workflow. For TransHans, KSeF e-invoicing and vehicle GPS run behind ticket sales. These are production integrations used every day, not proofs of concept. They are also the parts of a system that can fail quietly months after launch. We have developed our own SaaS product, Tesoro, since 2022, so we understand that responsibility as a product owner too.
You know the cost before the build starts, and you know who to call after it ends.
We discuss what needs to change, what the current process costs you, and who is involved. If an off-the-shelf product would do the job, we will tell you on that call.
We document the first version: what it will do, what it will leave out, and what can wait. That is the scope we price, and it does not quietly expand.
Each stage ends with something you can use and review. If we have misunderstood the process, you find out while it is still inexpensive to correct.
The people who built the system continue developing it. Regulations change, providers update their APIs, and new channels open. We handle these as normal changes to a system we already know, not as a new project that starts from scratch.
Mostly in writing. We work in English and our hours overlap with Western Europe, so we discuss questions on a call and record the answers in a document you can review and comment on. Nobody has to travel to approve the scope. Six months later, there is still a clear record of what was agreed, which matters on a long-running project.
You do, from the first week. The repository, environments, documentation and accounts with any provider we integrate are under your control, and we work within them. If you move the system to another team, there is nothing to buy back and nothing to untangle.
The same people you meet on the first call. We do not hand the build to subcontractors or move engineers between projects simply to fill gaps. The client we started working with in 2010 is still with us, and our low turnover makes that continuity possible. For an overseas buyer, the real question is not just the day rate, but whether the people who know the system will still be here next year.
Yes. That is how most of our projects begin. The first scope is a defined piece of work with its own price and finish line, not a retainer. If you stop there, you keep a working system and can still reach the people who built it. Most clients continue, but they make that decision after seeing the software in use.
Two practical safeguards make the difference. First, we write down the scope before pricing it, so there is a document to review instead of two people remembering a call differently. Second, we are not the cheapest option and do not claim to be. If price alone decides the project, it is better for both sides to establish that before work begins.
Tell us what the system needs to do and what the current setup is costing you. We will come back with a scope, a price, and an honest answer if we are not the right team for the job.