"It depends" is true, but it is not an answer

Every developer says cost depends on scope. That is correct and also useless if you are trying to decide whether to even start the conversation. So here is the actual breakdown of what drives price, with ranges based on the kind of projects I build.

What actually moves the number

Four things drive cost more than anything else:

• How many resources need to be scheduled. A single-court booking system is simpler than one juggling courts, coaches, and equipment with different availability rules.
• Payment handling. Taking a deposit through a payment gateway adds real work: webhooks, failed payment states, refunds, reconciliation.
• Integrations. LINE notifications, SMS, accounting software, existing POS systems — each one is its own small project bolted onto the core system.
• The admin layer. Customer-facing screens are usually the smaller half of the build. The internal tooling staff use every day — overrides, reporting, manual booking creation — often takes longer than the public site.

Two projects that look similar from the outside can differ by a factor of three once you account for these.

Rough ranges

These are typical ranges for projects I take on, not a price list. Treat them as a starting point for a conversation, not a quote.

• A focused internal tool (single workflow, one or two user roles, no payments): smaller end of the range, usually a few weeks of work.
• A booking system with payments (customer-facing booking, admin dashboard, payment gateway, notifications): the middle of the range, typically a couple of months.
• A full operational platform (bookings plus staff scheduling, reporting, multiple integrations): the top end, often an ongoing engagement rather than a single fixed project.

The honest answer only comes after a discovery call, because the scope questions above change the number more than anything I could put in a blog post.

Fixed price vs ongoing

For well-defined projects, a fixed price for a defined scope works well for both sides — you know the number before committing. For projects where the requirements are still taking shape, an ongoing arrangement (a set number of hours or a monthly retainer) fits better, because forcing a fixed scope on an undefined problem usually leads to change requests and friction later. I tell clients up front which model fits their project, rather than defaulting to one and adjusting after the fact.

Costs people forget to budget for

The build itself is usually not the only cost:

• Hosting. Modest for most small business systems, but not zero.
• Payment gateway fees. A percentage per transaction, set by the provider, not by me.
• Messaging costs. LINE and SMS providers charge per message once you go past free tiers.
• Ongoing support. Software needs occasional attention after launch — bug fixes, small adjustments, dependency updates. Budget for this the same way you would budget for maintaining a piece of equipment.

None of these are large individually, but a quote that only covers the build and ignores them sets the wrong expectation.

How to get an accurate number

Come to a call with the actual workflow you want to replace, not a feature list. "We take bookings through LINE and a paper diary, and double bookings happen most weeks" tells me far more than "we need a booking system." From there I can scope something real and give you a number that will not move much once we start. If you're not sure whether you've hit that point yet, here are the signs worth checking first, or reach out directly if you're ready.