When is a custom business application worth it?
Off the shelf software is enough as long as your business looks like everyone else's. Custom work makes sense when a rule specific to your activity fits no existing tool, when you spend your days copying data between spreadsheets, or when your product is itself a platform. For Eco-Actives, for example, a single host can only run one workshop at a time: booking a slot must hide every other workshop offered at the same moment. No stock module can express that rule, so it had to be written.
Conversely, if an existing tool covers 90% of your need, I will advise you to adopt it and, if needed, extend it with an integration rather than rewrite everything.
What I have already built
For Pitchichi, a consultancy that helps companies choose their communication agency, I wrote most of the Django REST API: 18 models across 6 apps, a needs qualification flow, an agency directory with portfolios, supervised background tasks and three environments. For ScienceProtect, I took part in a scientific monitoring platform: a Django then FastAPI API, publication ingestion and a knowledge graph.
These projects share a few traits: a data model designed before the screens, automated tests on business logic, reproducible deployment, and code someone else can take over.
My method, from scoping to production
I start by writing down with you the objects of your business and their rules, then the API contract before the first line of code. That is how the Arbre Agile website was built, with its HTTP contract specified in an OpenAPI file before implementation. Then I deliver in small steps you can try on a staging environment, never one big delivery after three months.
Every change goes through a branch, automated checks (lint, tests, typing) and a review before reaching staging, then production. You see the project move forward and you keep control over what goes live.
A sober, widely used stack
On the server, I use Python with Django when you need a back office and rich permissions, FastAPI when you need a fast, typed API. Data lives in PostgreSQL, sometimes in a graph database such as Memgraph when relationships are the core of the problem. On the front end, React and TanStack. Everything is containerised with Docker and deployed behind Traefik.
These are mainstream tools: if you hire a developer tomorrow or hand the project to another team, they will find standard, documented and tested code, not an in house technology.
Security, personal data and what comes next
A business application often handles sensitive data: customers, patients, donations, payments. I store the minimum required, hash passwords with suitable algorithms (argon2 on 24hprojects), prefer signed single use login links when users do not need an account, as for TapToSupport donors, and rate limit the exposed endpoints per visitor. Secrets stay on the server, never in code, and admin access is kept separate from user access.
After launch, the application keeps living: new rules, new users, library updates. I can maintain it myself, or hand it over to your team with handover documentation, tests that describe the expected behaviour and a deployment someone else can run. On 24hprojects, for example, the API is covered by 55 tests that also serve as living documentation.
Web or mobile?
Most business applications I build are web applications: they open in a browser, on a computer or a phone, without an app store, and an update reaches everyone at once. A native mobile app makes sense when it needs a phone feature a browser does not offer. That is the case for TapToSupport, where tap to pay requires an app installed from the Play Store: the Android app comes first, the iPhone later, and the API is shared by both.
A direct line to the person coding
You talk directly to the person who designs and writes the code. There is no project manager rephrasing, no information lost between sales and engineering. When a project needs more people, I say so from the start and rely on developers I have already worked with, as on ScienceProtect or Pitchichi, and I state it clearly.
I am not the right choice for a complex native mobile app to be delivered in a few weeks.
