Custom software for a small business in Europe: cost, timeline and what to ask a developer

Start with off-the-shelf software — then watch for these signs

For most small businesses, a good SaaS product is the right first step. Booking tools, accounting packages and simple stock apps are cheap, tested by thousands of users and ready today. Building your own only makes sense when the off-the-shelf tools start costing you more than they save.

These are the signs we see most often in businesses that are ready for something built around them:

• Staff copy the same data between two or three tools every day — orders into a spreadsheet, the spreadsheet into invoices.
• You pay for four subscriptions and still run the most important part of the business in Excel.
• Different people need different screens — a driver, a dispatcher and an owner should not all see the same thing — and your tool cannot do roles properly.
• Customers ask for something your tools cannot offer: live order status, a customer portal, online booking with deposits.
• You need the system to keep working when the internet is unreliable — in a van, a warehouse or a basement shop.
• You worry about where customer data is stored and who can see it.

What “custom” should mean for a small business

Custom software does not have to mean a huge project. For a small business, the best first version is usually narrow: one workflow, done properly, for the people who use it every day. A booking calendar with reminders. A job board for field staff. An order-to-invoice flow. A dashboard that shows today’s numbers without anyone building a report.

Keep the parts that already work. A custom system can send invoices into the accounting package you already use, take card payments through Stripe, and send messages through WhatsApp, SMS or email. You pay to build the part that makes your business different, not to rebuild everything that already exists.

Realistic budgets and timelines

Prices vary a lot by country and by team, so treat these as rough market ranges for work done by a small studio, not a quote. The biggest factor is not the technology — it is how many roles, screens and integrations the first release has to include.

• A focused internal tool or dashboard (one workflow, 1–2 roles, login and admin): roughly 4–8 weeks.
• A customer-facing web app with payments or bookings (customer side, staff side, admin, email and reminders): roughly 8–14 weeks.
• A multi-role platform with a mobile app, offline use or live updates: roughly 3–6 months, usually delivered in stages.
• Running costs after launch: hosting, domain, email or SMS sending, backups and a support plan — usually a small monthly amount compared with the build.

Real problems from our own projects

Every business thinks its case is unusual. In practice the same hard problems come up again and again. These are a few we have solved in software that is live today — they are the kind of details worth asking any developer about.

Live updates without refreshing. In Flow LGX, a logistics operations dashboard (flowlgx.com), five roles — super admin, admin, staff, distributor and dispatcher — each get their own dashboard, and notifications arrive over a live connection, so a dispatcher sees a change the moment it happens instead of reloading the page.

Working when the internet does not. In Karobar, our shop billing app (karobar.techroof.it.com), a bill saved without internet is kept on the device and sent to the server when the connection returns. Each bill and each stock adjustment is applied exactly once, so a slow network or a double tap cannot create duplicate bills or count stock twice.

Staying up when it matters most. Stadium Pulse Live (app.stadiumpulselive.com) is used by venue staff during live events. We treated the real-time parts as their own milestone and did not call the product live until event staff had used it under busy, event-like conditions.

Letting the team run it without a developer. For Youth Sportify (youthsportify.com), coaches and content admins publish programmes and videos themselves. The admin side was planned as carefully as the public site, because software the client cannot run alone is not finished.

GDPR and data: the basics to agree up front

If you serve customers in the UK or EU, you are responsible for their personal data even when a developer builds and hosts the system. You do not need to be a lawyer, but agree these points before work starts and put them in writing:

• Where the data is hosted, and whether that region suits your customers (many EU businesses prefer EU hosting).
• Who can see customer data — by role inside the app, and on the developer’s side during support.
• How data is backed up, how often, and how quickly it can be restored.
• How a customer’s data can be exported or deleted when they ask.
• A data processing agreement (DPA) with the developer or hosting company if they handle personal data for you.
• Cookie consent on public pages if you use analytics or advertising.

10 questions to ask before you hire a developer

Good developers welcome these questions. Vague answers are a warning sign.

• Can I see live software you have built — real URLs, not just screenshots?
• How do you split the work into milestones, and what do I see working at the end of each one?
• Who owns the source code and the design files when the project is finished?
• Where will it be hosted, and who holds the hosting and domain accounts?
• How do you handle logins, passwords and user roles?
• What happens if the internet is slow or drops in the middle of an action?
• How are backups done, and have you ever restored one?
• What does support cost after launch, and how fast do you respond to a problem?
• How will my team learn to use it — is there a walkthrough or short guide?
• If we stop working together, how does another developer take over?

How a good project runs

The safest way to buy software is in small, signed stages: discovery and scope, screen designs, a working version you can click, the full build, then launch and handover. You review working software at each stage — not slides — and you only move on when you are happy with what you have seen.

Launch should not be the end of the relationship. Plan for the first week after go-live, when real users find the things no one thought of. A developer who stays close during that week saves you far more than they cost.

The bottom line

Use ready-made tools while they fit. When the workarounds start costing more than they save, build the one workflow that matters most, keep everything else, and hire a team that shows you live work and answers the hard questions plainly. If you want a second opinion on your idea, TECHROOF.IT offers a short discovery call — there is no obligation to build with us.