Skip to content

// business applications practice

Business applications, designed with you

A joint study first, a bespoke application second.

A spreadsheet that has become unmanageable, paper forms, a process everyone runs their own way: before writing a line of code, we start from your real tools and build the requirement with you. And if an existing solution already meets it, we tell you.

// 01 · the joint study

Seven principles, before the first line of code

The study is short, and it produces documents you keep: a scoping note, a mock-up, a specification. Its first purpose is to decide whether to build at all.

  1. Start from your real tools

    We analyse and measure your existing files, forms and ways of working, then play back what we have understood: what works and should be kept, what gets in the way. No blank page.

  2. A first draft, which you correct

    The scoping note and then the specification are working documents, written in your language and meant to be annotated. They separate what you said from what we propose, so everyone knows what they are signing off.

  3. Show before building

    A clickable mock-up built on your own de-identified data: you recognise your work in it, test it in a meeting, and can present it to your management.

  4. Your data protected from the study onwards

    Anonymisation is tool-assisted and checked, we keep only what is strictly necessary, and data protection is a design requirement, not an end-of-project step.

  5. The right questions, with a default answer

    Open questions are listed and ranked (blocking, important, nice to have), and each carries a default proposal: the project moves forward without waiting for everything to be settled.

  6. A project split into lots

    A first lot cut down to the essentials, measurable success criteria, and what is out of scope written down in black and white. Then a pilot in real conditions before rollout.

  7. Check the risky points before committing

    A technical test on your workstations or on a real phone, a review of existing solutions, a check of what the tool already in place covers. Bespoke development has to be justified, never assumed.

// 02 · projects

Real projects

Very different needs, the same method. Clients are not named; the first two projects are for the same industrial company.

Industrial maintenance · workshop

From job to acceptance test, one tool

The need
A complete process (job, inspection, quote, purchasing, manufacturing, internal and customer acceptance testing) spread across macro-driven workbooks, multi-tab Excel reports, paper routings and PDFs. Reliability, traceability and cost analysis all suffered.
The study
Sixteen source documents analysed one by one, reverse-engineering of the workbooks (which revealed gaps between the tool and actual practice), sixty-five questions in nine themes, each with a default answer, then a consolidated specification and a delivery plan in five lots.
The answer
A web application usable on a tablet in the workshop, with role-based access and acceptance reports generated as PDF. Built on our specifications, it is in production, and we supported the client through its rollout.

Industry · management

Dictate a task, get reminded

The need
Tasks jotted down on the fly got lost or piled up without ever being closed. The need: dictate a task on a phone, then be reminded until it is dealt with.
The study
A scoping note separating the client’s request from our proposals, an honest review of competing products, the client’s written critique and prototype, a point-by-point response, a specification in three days. Requirement set from day one: under five seconds and two gestures from unlocking the phone to saving a task.
The answer
A mobile application for Android and iOS backed by a server, with reminders by notification and then by text message. In development, co-built with the client.

HR · finance · general management

Support functions too

The need
Skills and training tracking, management dashboards, consolidations and trade-offs: these needs often live in shared spreadsheets that have become fragile, with no reliable history or access rights, where each update overwrites the last.
The study
The same method: start from the real file, a mock-up on your de-identified data, a specification you amend, and an upfront check of what your existing tools already cover.
The answer
Studies are under way for these functions. We do not detail them here, but we are happy to talk about them.

// 03 · frequently asked questions

What we are asked before we start

Do we need a specification to get started?

No. The specification is an output of the study, not a prerequisite: we write it from your tools and our conversations, and you amend it until it says what you want.

What if an off-the-shelf product already does the job?

We tell you. The study checks what the tool already in place covers and what existing solutions offer before recommending any development. Bespoke software that duplicates an existing tool costs twice.

Is our data used for the mock-up?

Yes, that is what makes it meaningful, but de-identified by a tool-assisted process that checks no name remains. Mock-ups stay between you and us: they are never published.

A business application lives inside an existing information system: its architecture, integrations and operation draw on our software architecture expertise.

Tell us about your need