Custom Web Apps vs Off-the-Shelf Software: When to Build

Every growing business hits this fork. Keep paying for SaaS that almost fits, or invest in something built for how you actually work. The honest answer is "it depends" but it depends on three or four specific things, not on vibes.

The hidden cost of "good enough"

SaaS is great until it is not. The hidden costs show up as:

• You pay for 100 features and your team uses 5.
• The team has three workarounds for things the software cannot do. Each workaround takes 10 minutes a day. Across ten people that is over an hour daily of pure friction.
• You export to Excel because the built-in reports do not match the metrics you actually care about.
• You manually copy data between two SaaS tools that do not integrate.
• You need a workflow that no product on the market supports, so a junior staffer becomes the workflow.

A team of 10 spending 30 minutes a day on manual workarounds burns roughly 1,300 hours a year. At Polish or EU loaded labor rates, that is somewhere between 40,000 and 90,000 EUR a year of pure waste, depending on the team.

That is the number you compare custom development against. Not the sticker price of the SaaS.

When off-the-shelf wins

Buy SaaS when:

• The problem is common and solved. CRM, email marketing, transactional email, project management. Thousands of companies have the same need. Pay HubSpot or Pipedrive 200 EUR a month and move on.
• Your process is standard. You can adapt your workflow to the tool without pain. The tool was built for your kind of business.
• Speed matters more than fit. You need something working today, not in three weeks.
• Your budget is under 2,000 EUR for the build. Below that threshold, custom development almost never makes sense.

Examples we recommend to clients all the time: Slack for team chat, HubSpot or Pipedrive for CRM, Notion for internal docs, Stripe for payments, Resend or Postmark for transactional email, Cal.com for booking (the founder of FlowBity actually self-hosts Cal.com on the same VPS that serves this site).

When custom wins

Build custom when:

• Your process is part of your competitive advantage. The way you do things is unique and valuable. Codifying it in your own software locks it in.
• No SaaS fits. You have tried 3 to 5 tools, none of them do the thing you need, and you have stopped getting demos that match your reality.
• Integration is the core need. You need 4 systems to talk to each other in a specific way, and "Zapier with 8 zaps" has become its own maintenance burden.
• Data ownership matters. You handle patient data, financial records, trade secrets, or anything where exporting to a third-party SaaS is a deal-breaker.
• The math works. A 10,000 EUR custom build that saves 2,000 EUR a month in manual work pays for itself in 5 months and then keeps paying.

Examples: client portals, internal operations dashboards, custom booking flows that SaaS cannot model, proprietary data pipelines, ETL between legacy systems.

The 3-question framework

Before you decide, answer these honestly:

Can you describe the exact workflow on a whiteboard?

If you can write down step by step what the tool should do, you can build it. If your description is "we need better project management", buy something off-the-shelf and learn what you actually need from using it. Custom built on vague requirements is the most expensive mistake in this category.

Will it save more than it costs within 12 months?

A 10,000 EUR custom app that saves the team 15 hours a week pays for itself in about 3 months at EU labor rates. A 10,000 EUR app that saves 2 hours a week takes over a year, and that is before maintenance. The 12-month payback rule is the line between "build" and "wait until next year".

Is the data sensitive, regulated, or proprietary?

If you handle patient data under GDPR, financial records under PSD2, or trade secrets you cannot put on a US-hosted SaaS, custom gives you control over where data lives and who can read it. Cost is secondary to compliance here.

What a custom build actually looks like

For most of our internal-tool projects, the week-by-week looks something like this:

• Week 1: Discovery call, scope document, wireframes, schema sketch.
• Week 2: Backend API plus database, first working slice (one core flow end to end).
• Week 3: Frontend, integrations with existing tools, internal testing.
• Week 4: Deployment, team training, handover with full source code and docs.

Tech stack we default to: Next.js plus FastAPI plus PostgreSQL. Boring on purpose because boring is reliable, well-documented, and easy to hire for if you want to bring it in-house later.

What you get on day one: the repo, the database, the deploy keys, the documentation. No vendor lock-in. If you fire us, you keep everything that runs.

The hybrid approach (most clients land here)

Pure custom and pure SaaS are both rare. The realistic answer for most growing companies:

1. Use best-in-class SaaS for commoditized needs. CRM, email, payments, scheduling. Do not reinvent these wheels.
2. Build custom glue that connects them. The 800-line Python service that syncs HubSpot to your accounting tool the way your specific business needs it.
3. Build custom tools only for your differentiated workflows. The portal your clients log into, the dashboard your ops team lives in, the AI agent that handles your specific pipeline.

That is the architecture we recommend to most clients. It is not the most exciting answer. It is the one that saves money.

If your SaaS bill is growing

If you are looking at a SaaS bill that grew 60 percent in the last year while your team's manual workarounds also grew, it is probably time for a discovery call. We will tell you which of the three categories above your case actually fits. Sometimes the honest answer is "just buy the SaaS", and we will say that out loud.