Solutions by industry
Online bus ticket sales and software for carriers
I build online bus ticket sales as a custom web application, from €2,500, with a typical timeline of 4–10 weeks. It's built for carriers who want connected sales, passenger records and daily operations in one place. Scope can include seat selection, QR tickets, fiscal receipts and an admin panel, delivered in agreed phases.
One record for the website, the office and boarding
A ticket sold online changes what the office and the crew see at departure. If each channel keeps its own spreadsheet, seats, payment status or the passenger list stop matching sooner or later. So design starts from a shared record. We define exactly what happens when an operator enters a reservation, a passenger pays online, or a departure changes.
International routes have more stops, rules and exceptions than a simple product purchase. It matters to separate a route from a specific departure date, and a ticket from a request that isn't confirmed yet. Before development we go through real examples from your operations, including a failed payment and a changed trip, and use them to check whether the proposed system actually fits how your staff work.
What a carrier system can include
Routes, stops and departures
You manage routes, stops and specific departures from one panel. We agree how sales deadlines work and how time is shown to the passenger. Changing one departure should never silently change data on tickets already issued.
Seat map and availability
The passenger picks a seat based on the bus layout. The system needs to prevent two simultaneous purchases from confirming the same seat. We also agree on temporary seat holds, reservation expiry, and what happens when payment isn't completed.
Sales across multiple channels
Online sales and office entries share the same agreed data source. If you have partners or sales points, we define their access. Every channel needs to clearly distinguish a reserved, paid, cancelled and used ticket.
A ticket with a QR code
Once confirmed, a ticket is issued with trip details and a code used for validation. It's designed for both phone screens and printing. Resending a ticket should be simple, without creating a second valid ticket for the same passenger.
Boarding checks
Staff scan the ticket and see its status in the system straight away. We agree how the system handles a repeated scan or the wrong departure. If field work needs a dedicated mobile tool, that's scoped separately.
Payments and fiscal receipts
Integrations are planned around the providers you use and requirements confirmed with your accountant. Handling failed payments, refunds and repeated notifications is part of the spec. The technical connection needs to follow the real transaction status, not just whether a confirmation page opened.
Roles and access control
A sales operator, a dispatcher and an administrator don't need the same permissions. We agree who changes prices, who cancels a sale, and who sees reports — which limits how much damage one accidental change can do to a departure.
Passenger lists and operational reports
Passenger, occupancy and sales views are built around what the office and the road crew actually need. Required exports are agreed on real examples. A report should explain the underlying data and sales status, not just show a total.
Cost and timeline
| Package | Starting price | Typical timeline |
|---|---|---|
| Custom web application | from €2,500 | 4–10 weeks |
The starting price in the price list covers the agreed application — not a complete system with every possible sales channel. The number of integrations, different fare models, partners, mobile tools and migrating an old database all change the scope. During the estimate we decide what has to work at first launch and what can follow.
The 4–10 weeks window applies to the agreed scope. Access to your payment provider, a test environment and content you supply all affect the actual schedule. In the fixed quote, development and any external costs are listed separately. You get it within 48h of a short call and clarifying the requirements — I don't assume every carrier is organised the same way.
A real project
For Srbija Tours I built DriveSoft, a booking and ticketing platform for an international bus carrier. It has processed 150,000+ tickets and reservations, with 100+ internal users. It covers QR validation, fiscal receipts and an admin panel, along with passengers, routes, departures and reporting.
That's evidence of production experience, not a promise that your project automatically gets the same scope for the starting price. In the case study you can see the flow from choosing a departure to boarding, and the role of each part of the platform. Your sales rules, staff permissions and existing infrastructure remain the basis for a new system's specification.
Why work directly with a developer, not an agency
One person from the call to the server
You agree on scope with me, follow development, and take over a finished site. Questions go straight to the person writing the code.
A fixed quote for the agreed work
You get a price, scope and phases within 48h of a short call. Anything beyond that scope is agreed in advance, separately.
No agency markup
Working directly can be more affordable than an agency, since you pay for development and the services you actually need, with clear accountability for delivery.
Maintenance from €50/month
Fixes are free for the first 30 days after launch. Ongoing support and maintenance are agreed separately, based on the pricing page.
How working together looks
- 01
Free call
30 minutes — we go through what you need, budget and timeline. No obligations.
- 02
Fixed quote in 48h
You get an exact price, scope and a phased delivery plan. The price does not change afterwards.
- 03
Development in phases
I work in weekly phases with reviews — you see progress and give feedback along the way.
- 04
Launch + 30 days of support
Server setup, training and a month of free fixes after launch.
Questions about ticket sales and operations
Can the office sell the same seats as the website?
Yes — the goal is a shared availability record, but how it connects depends on the software you already use. If we're building both channels, they're designed around the same sales database from the start. If an existing system stays in place, I first review its interface. Two disconnected records aren't a reliable way to sell the same capacity twice over.
What happens when a payment fails?
The spec defines how long a seat is held, when it's released, and how the passenger continues the purchase. Payment status is confirmed by the payment provider. We specifically handle delayed notifications and retried attempts, so you never end up with two tickets or a seat marked taken without a confirmed sale. Those cases are tested before launch.
Can we keep our existing passenger and departure data?
An import can be planned if the data exists in an accessible format and you have the right to use it. I review the structure on a sample first, without unnecessary personal data. Stops, routes, statuses and duplicates need reconciling. Migrating history and any downtime during the switch go into the plan, with results checked before final cutover.
Does QR validation work without internet?
That depends on the field tool we agree on. Working with an intermittent connection needs rules for downloading data, checking locally, and syncing later. I don't silently include that in every web application. First we establish where the crew works, what devices they use, and the risk of the same ticket being validated more than once.
Are all fiscal obligations handled automatically?
I build the technical integration around requirements confirmed for your business and your chosen provider. Your accountant or another qualified expert determines the obligations and how specific situations are handled. Sales, cancellations and refunds are tested against those rules. Software doesn't replace that check, and I don't promise an identical setup for every market.
Can the system be introduced gradually?
Yes. It's common to define one complete sales flow and office processing first, then add other channels and reports. Each phase needs a clear boundary and a way to verify it. During the transition we agree where the authoritative record lives, so staff never end up maintaining two different versions of the same departure at once.
Let's walk through one of your departures together
Describe how you currently sell tickets, track seats and check passengers. From that I prepare a system proposal, a rollout order, and a fixed quote for the agreed first version.
Get a quote