Your SME may already be paying for its custom business application.
Not through a supplier invoice. Through time lost every week, double entry, forgotten follow-ups, copied Excel files and approvals stuck with the founder or manager.
The real signal is not “we want an app”. The real signal is simpler: your team has already built software by hand.
An Excel file to track. A form to collect. An email to approve. A Drive folder to store. A Slack message to notify. Then someone copies, checks, follows up and fixes.
On paper, it looks free. In real business, it costs every month.
A custom business application often starts with a workaround that works
A workaround is not a failure. It is often proof that the need exists.
An SME tracking customer requests in Excel has already done part of the work. It knows which columns matter. It knows who intervenes. It knows which errors come back. It knows where the process gets stuck.
Concrete example: a team receives requests through a form. It copies them into a spreadsheet. It adds a status. It prepares a quote. It waits for management approval. It follows up with the customer. It archives the documents.
At first, the spreadsheet is enough. Then the file becomes the friction point: two versions circulate, one row changes without history, a follow-up leaves too late, the founder becomes the only place where the decision moves.
At that moment, the topic is no longer “make it cleaner”. The topic is business: remove the friction slowing the team down.
That is when a custom business application starts to make sense.
The wrong reflex: asking for a large platform
When the workaround cracks, many founders start too big.
They want to replace everything at once: CRM, quotes, invoicing, documents, customer tracking, alerts, analytics, customer portal, internal roles.
The quote grows. The timeline grows. The number of meetings grows. The risk grows too, even though the original problem was often much smaller.
The first useful piece often fits in one sentence: centralize requests and track their status. Or generate a quote from clean data. Or remove double entry between two tools. Or give customers a simple page to track their file.
A custom business application should not start as a factory. It should start with the brick that removes the most visible hidden cost.
At 5000.dev, the first brick costs 5,000 euros excl. VAT, takes 2 weeks of development and must deliver a concrete result. If the need is larger, we split it. If it cannot be split, the problem is not clear enough yet.
The calculation SMEs delay
The question is not “how much does an application cost”. The question is “how much does the current system cost”.
Take a simple process.
One person spends 30 minutes a day copying information between a form, a spreadsheet and an invoicing tool. That is roughly 10 hours per month. Add fixes, missed follow-ups, manual checks and late approvals. The cost is no longer just admin time. It becomes commercial.
A quote sent two days too late can lose a sale. A wrong status can trigger a useless call. A founder approving everything at night blocks the team from moving faster.
After 90+ projects, the same pattern keeps coming back: the visible issue is a file. The real issue is a work loop that depends too much on one person.
A custom business application captures that loop. It does not exist to impress anyone with a large dashboard.
Three cases where Excel should stay
Excel deserves more respect than agencies usually give it.
Keep Excel if the process changes every day, if only one person uses it, if you are still discovering the right columns, if no business decision depends on the file.
Example: you test a new offer for one month. You receive ten requests. You change the criteria every week. Building an app would be too early. A shared spreadsheet and a few customer calls are enough.
Also keep Excel if the risk of error is low. An internal supplier list updated once per quarter does not always deserve an application.
Custom software becomes interesting when the workaround has proven its value and starts costing more than its transformation.
Three cases where SaaS is enough
Standard SaaS is enough when your need looks like the need of thousands of other companies.
Accounting, email marketing, electronic signatures, classic support: many tools already do the job well. An SME does not need to rebuild what already works.
The signal changes when you pay for SaaS and use it like a prettier spreadsheet. You bypass fields. You export data. You add columns outside the tool. You paste notes where they do not belong.
A SaaS at 400 euros per month used at 30% can cost more than it seems. Over 3 years, that is 14,400 euros, without code ownership and with a process that may still feel awkward.
The right call is not ideological. Keep SaaS when it fits the work. Build a first brick when your team spends its time working around the tool.
The real signal: one business action repeats every week
A custom business application makes sense when the same action comes back often, with rules stable enough to write down.
Example: create a customer file, check documents, assign a status, generate a document, notify the right person, keep a trace.
The visible button can be simple. The action behind the button creates the value.
Many quotes miss that difference. They price screens. The founder buys an outcome. Between the two, someone has to translate the business into simple rules.
Here is the practical test: if you can describe the flow in 6 screens and one central rule, you probably have a first brick. If you need 40 screens to start, you are probably mixing several problems.
You can compare this logic with building internal software for SMEs and replace Excel with an application.
What the first brick should include
The first brick should not cover the whole company. It should prove that the right process deserves automation.
It can include:
- an internal or customer form,
- a clean database with the right statuses,
- a filterable list,
- a detail screen,
- one clear business action,
- a useful notification or export,
- simple permissions if several roles are involved.
Example: an SME manages quote requests. The first brick can cover incoming requests, qualification, status, a simple document generation and follow-up history. You do not need to build the whole CRM to remove the bottleneck.
That type of brick creates two results: the team saves time, and management sees the next step from real usage.
What 5000.dev simplifies
5000.dev was built for this exact moment: an SME has a clear business problem and does not want a 6-month tunnel.
The model is readable: 5,000 euros excl. VAT, 2 weeks of development per brick, delivered or refunded. Code is delivered. Scoping happens before development starts. Development starts when the perimeter is clear enough to hold.
This avoids two classic traps.
First trap: paying a large quote to cover fear. The quote protects the provider, but it does not always guarantee fast usage.
Second trap: staying in Excel because the project feels too big. Between the homemade file and the full platform, there is a simpler path: one useful first brick.
To understand the pricing model, read 5,000 euro web application. To discuss the scope, start from 5000.dev.
SME owner FAQ
How much does a custom business application cost for an SME?
At 5000.dev, a first brick costs 5,000 euros excl. VAT for 2 weeks of development. A complete application may need several bricks. The point of the model is to make the budget visible at every step, instead of signing a large vague project from day one.
When should Excel be replaced by a business application?
The right time comes when the file becomes a bottleneck: frequent double entry, errors, competing versions, forgotten follow-ups, approval stuck with one person. If Excel is still helping you test an unstable process, keep it.
Does a custom business application always replace SaaS?
No. Standard SaaS makes sense when it covers the need well. Custom software becomes relevant when your team works around the tool, exports data, pastes things back into Excel or pays every month for software that does not really fit the work.
If your team has already built its software by hand, the next move is to isolate the first useful brick and see what can be shipped in 2 weeks with 5000.dev.