Full project

Custom web application development

One point of contact from scoping to production, instead of a chain of suppliers passing problems between them.

When a custom application is justified

Not always. An off-the-shelf tool costs less and ships faster: if your need fits inside one, that is the right answer and I will say so. Custom development earns its place in a few specific situations.

  • Your process fits no existing tool without contortions
  • You pay for several products to cover what one would do better
  • Your data is scattered and nobody has the full picture
  • A significant share of the work still happens through files passed around by hand
  • The tool you use locks you in and you want out

How a project runs

  1. Scoping: understand the need, the existing estate and the constraints, and write down what the first batch will contain and, above all, what it will not
  2. Design: architecture, data model, user journeys
  3. Iterative development, with something to look at regularly rather than a single delivery at the end
  4. Acceptance testing with you, on your real data
  5. Go-live, monitoring, documentation and handover

What you receive at delivery

  • The source code, in your repository and under your name
  • The infrastructure described as code, reproducible
  • The deployment pipeline, working
  • Technical documentation and administrator access
  • Monitoring in place, with alerts configured

This deserves saying plainly: you own everything. No dependency on a closed platform, no code I keep, no access I alone hold.

Business applications delivered

A delivery platform with three connected applications, a parcel transport marketplace, a fleet and contract management tool, and a job application system with automated CV parsing.

See the eleven documented projects

Frequently asked questions

How does a project start?

With a conversation about your need, at no commitment. If the project makes sense, I propose a written scope for the first batch, stating what is in and what is deferred.

What if the requirements change along the way?

They almost always do, which is why I work in batches rather than a single delivery. A change is handled by rearbitrating the content of the next batch.

What happens after go-live?

I stay available for fixes and further work. Handover is part of the delivery, so that you do not depend on my availability.

Let's talk about your project

Describe your need in a few lines. I will tell you what is feasible, what is not, and where to start.

Get in touch