Custom business application development
for tools your teams actually use.

A business application is an internal tool built for one specific process in your company: service call tracking, quotes, scheduling, customer requests, quality control. It replaces the spreadsheets that contradict each other and the re-keying between software systems. At Bonne Idée, we build it in four months, scoping included.

With you, we write down the process as it really happens, cut what doesn’t serve it, design the screens, then build the tool. AI is added where it saves time, using the same method as an LLM integration.

You get a tool in service, used by your teams with your real data, with role-based permissions and documentation that lets someone else take it over.

You have no specification to write, no technology to choose and no hiring to start before you know what needs to be built. If you are launching a new product to sell rather than an internal tool, what you need is an MVP.

Your teams will use the tool every day, for years, and that determines how it is built. An impressive prototype that doesn’t hold up for three months doesn’t leave our hands: what we deliver has a carefully designed data model and managed permissions, and can evolve without being rebuilt.

An application that does everything you had imagined and that your teams work around has cost four months for nothing. An application that does only one thing, but that the whole department opens every morning, has already replaced the spreadsheet.

The choice between code and platform is a calculation, and we explain below how we make it.

Most internal tools that fail don’t fail during the build. They fail because no one had written down, before starting, the process they were meant to serve. The result is software that reproduces the spreadsheet, flaws included.

What scoping writes down

Who enters what, when, and from which source. Who approves, and what happens when they say no. What has to come out: a quote, a schedule, a work order, a dashboard. And the exceptions, the ones that aren’t written down anywhere and that your teams handle from memory.

Three things a good internal tool proves quickly

• That data is entered only once. If a piece of information still has to be copied somewhere else, the tool has missed its target.
• That the user journey stands up without lengthy training. If a team needs a demonstration to use it, the tool isn’t ready.
• That usage repeats. The tool’s real competitor is the spreadsheet that already works.

The written scope, and what it prevents

At the end of scoping, you have a list of what will be built and, above all, a list of what won’t. The second one protects the project. Without it, every week brings a new idea, each one reasonable on its own, and the tool drifts until the budget runs out before go-live.

That list is dated: what doesn’t make it into the first phase goes into the next, and that phase is decided with the usage data from the first.

The question always comes up too early. It is settled quickly once the process is written down, and it takes weeks when it is asked before.

The criteria that decide

• Volume and logic. A platform is enough for data entry screens, filtered lists and role-based permissions. Code becomes necessary when the logic gets complex, the volume climbs or a security constraint requires it.
• The software to connect. Accounting, CRM, ERP: an internal tool that doesn’t talk to the others recreates re-keying. The Consulting practice handles these connections through business tool integration.
• Who will maintain the tool. An in-house technical team, us, or another vendor: the answer changes the choice.
• The device. A tool used sitting at a screen lives in a browser. A tool pulled out of a pocket on a job site, with photos and geolocation, lives on a phone.

AI-assisted app generators, and where they really fit

In a few hours they produce a credible interface, and that is a real gain for showing a direction. Their limit appears as soon as what was generated has to evolve: the data model is often implicit, the logic scattered, and taking it over costs more than the initial build saved. We use them to explore quickly, rarely as a foundation. We detail what each one can do in our Bolt or Lovable comparison.

What doesn’t depend on the tool

A data model thought through before the first page, because it is the one thing you can’t fix later without redoing everything. Permissions managed at the data level and not at the display level, because a hidden button is not protection. And consistent naming conventions, so that the person who takes over the tool a year from now understands what they are looking at.

When the tool needs to answer from your documents, it relies on an AI agent.

Every development platform has a ceiling. Keeping quiet about it would be convenient at the sales stage and costly in use, so we raise it from scoping onward.

The four signs that the ceiling is near

• Load times deteriorate on screens that handle a lot of rows, and optimization is no longer enough.
• A compliance requirement demands control over hosting or encryption that the platform doesn’t allow.
• The cost of the platform, tied to usage, becomes comparable to the cost of a technical team.
• The business logic becomes specific enough that you spend more time working around the tool than using it.

None of these signs shows up in the first few months. They come with success, and the ceiling then becomes a growth problem.

Migration, when the question arises

A tool built on a platform doesn’t convert into code automatically. What does transfer, however, is what costs the most to produce: the validated data model, the user journeys proven by real users, the written business rules, and the knowledge of what serves no purpose. A technical team that starts with that doesn’t build the same thing as a team that starts with a specification.

That is also why the choice is made during scoping: when these signs are foreseeable from the start, we build directly in code.

How we limit lock-in from the start

The data must be exportable in a readable format, and we check that at the start of the project, not on the day the question comes up. The business logic is documented in French, outside the tool, so that it outlives the platform. And connections to your other software go through standard mechanisms, which makes them reproducible elsewhere. When those connections become numerous, they are in fact more a matter of process automation than of the product itself.

An internal tool is a two-party project, and the workload on the client side is the variable no one mentions at signing. We prefer to put it in writing.

What we expect from you, in concrete terms

• One person who decides, available one to two hours a week, with the authority to make the call without escalating the question elsewhere. This is the single biggest factor in meeting the deadline.
• Access to the people who will do the work in the tool, not only those who describe it. Without them, the tool gets validated among ourselves, which validates nothing.
• Knowledge of your business, which we don’t have and will never have as well as you do. The unwritten rules, the exceptions, the special cases that aren’t written down anywhere.
• Real content when there is any: a product filled with dummy text is hard to test, because users react to substance as much as to form.

What we take on

Designing the user journeys, the build, the data model, permissions, deployment, and preparing the test sessions. We also take on the most thankless job in the project, which is defending the written scope: pointing out, every time a new idea comes up, that it may be a good one but that it isn’t in the current phase.

The pace, and why it is short

Two-week cycles protect the project: a project that shows nothing for two months has no way of knowing it is drifting, and discovers the gap at the point where it costs the most to fix.

The flip side is that you will see imperfect versions early. An intermediate version that doesn’t look finished is normal. What should worry you is a project that shows nothing.

What derails projects, in our experience

Three causes keep coming back, and none of them is technical. A decision waiting on a meeting that never gets scheduled. A scope reopened without the deadline being reopened with it. And teams that can never be freed up to try the tool, so that it ends up being judged on management opinions. We flag these three situations as soon as they appear, rather than absorbing them in silence until delivery.

Comparing two quotes for a first version makes no sense until you know what each one includes. Here is our breakdown, so that a comparison is possible.

What is always included

• The two-week scoping, meaning writing down the process the tool will serve and the scope that goes with it.
• The design of the user journeys and screens, which is where the real work lies.
• The build, the data model and permission management.
• Deployment, then onboarding your team, with the documentation that goes with it.

What is quoted separately, and why

Platform subscriptions, because they are in your name and depend on your usage volume. Migrating legacy data, because the effort depends on its condition. Connections to your management tools, because a CRM integration is a project in its own right.

We quote them separately so that you can see each trade-off. The project itself gets a custom quote, after a first call.

After go-live

After deployment, what comes next is decided on usage data: a new quoted phase, or the Partner plan if requests become continuous.

A business application centralizes data that your teams used to copy from one spreadsheet to another: it is better protected once it is in one place, with permissions managed at the data level. A data processing agreement (DPA) is signed with the contract, hosting is in France by default, or on your own infrastructure when the sensitivity of the data requires it, and when the tool includes AI, no model is trained on your data.

GDPR, the EU AI Act and human review are covered in detail on our AI guarantees and data sovereignty page.