Get in touch

From the business problem to a live product.

We don't sell developer hours. We deliver a working product, with scope approved before it exists, and we stay until the team adopts it.

How we work

How we work, phase by phase.

Every project goes through the same four phases. What changes is the size of each one.

  1. Discovery

    We sit down with you and with the people who run the process every day. We map how the operation really works: where information comes in, how many hands it passes through, where it gets stuck and what that costs. We also point out what should not become software. Automating a bad process only makes the mistake faster.

    You get A map of the current process, a list of bottlenecks ranked by impact and a recommendation of what to build first.

  2. Product Concept

    We define what goes into the first version, what waits and what isn't worth building. We design the main screens and the user flow. No development starts before you approve it.

    You get A scope document, a clickable prototype of the main screens, a timeline and a fixed proposal.

  3. Build

    Typical duration: depends on scope

    Development in short cycles, with a test environment live from the start. You watch the product grow instead of waiting for a surprise final delivery. Our team uses AI at every production stage, including discovery, code, testing and QA. That's what lets a lean team deliver fast. It's our tool, not a promise to you.

    You get Working partial deliveries, a check-in at every cycle and a direct line to the people building it.

  4. Operation

    Typical duration: ongoing

    We launch, migrate the data that needs to come along, train the people who will use it and follow real usage in the first weeks. Software nobody adopts hasn't solved anything.

    You get A product in production on your infrastructure, documentation, team training and post-launch support.
01 / 05

Product Discovery

Clarity before building

What it is

The phase where the problem becomes clear enough to turn into a decision. We look into how the business works, talk to the people who operate and the people who decide, and separate symptoms from causes. You come out knowing what to build first and what not to build yet.

What you get

  • A map of the current process or journey, showing where it gets stuck
  • A list of opportunities ranked by impact and effort
  • Product hypotheses and risks, with what needs validating first
  • A scope recommendation for the first version
  • Effort and investment estimates for the next phases
02 / 05

Product Concept

The shape the solution will take

What it is

The discovery decision becomes a designed product: flows, information architecture and main screens. You click through the prototype before a single line of code exists, which is where change is cheap.

What you get

  • Information architecture and user flows
  • A clickable prototype of the main screens
  • A locked first-version scope, with what was left out spelled out
  • A prioritized backlog and timeline
  • An early technical definition of the architecture
03 / 05

Build

Software development

What it is

Building the product, in short cycles, with a test environment live from the start. It works for an MVP when there's no tech team yet and for an internal system when a business wants to stop improvising.

What you get

  • A web app, PWA or internal system in production
  • Integration with the tools you already use
  • Migration of the data that lives in spreadsheets today
  • Code, data and access in your name, on your infrastructure
  • Documentation, team training and post-launch support

Ongoing care: Build clients can leave the product in our care after delivery, with fixes, monitoring and new features in defined cycles. We agree on this at the end of the project. It's not a separate package you need to choose now.

04 / 05

Product Identity

Visual consistency in digital

What it is

The set of standards that makes a product feel like one product, even as it grows screen by screen and passes through different hands. Components, states and usage rules in a library the team can follow without having to ask.

What you get

  • An interface component library, with states and variations
  • Color, typography and spacing tokens
  • Patterns for navigation, forms, tables, empty, loading and error states
  • A written usage guide, with dos and don'ts
  • Files delivered in the format your team uses
05 / 05

Branding Development

The brand the product needs

What it is

For people creating a new company or product who need a brand before going to market. Positioning, verbal identity and visual identity. A brand here isn't a pretty logo. It's the decision about what the company is and how it speaks.

What you get

  • Brand platform: positioning, value proposition, territory and archetype
  • Verbal identity: tone of voice, vocabulary and what the brand doesn't say
  • Visual identity: logo, palette, typography and supporting elements
  • Brand guidelines and an application kit

Questions we hear all the time.

It depends on scope, and scope only exists after discovery. In practice, a small project and a large one start the same way: a 30 to 45 minute conversation. If what you need does not fit what you can invest, we say so in that first conversation and not in the middle of the project.

It depends on scope. What doesn't change is the method: you approve scope and screens before development starts, and you see the product working in short cycles, not only at the end.

No. Each one solves a different problem and can be hired on its own. If you already have discovery done, we start with Product Concept. If you know exactly what you want, we start with Build.

If your operation already hurts, it's big enough. Custom software isn't only for large companies. It's for companies whose process doesn't fit a generic tool.

It does in two cases: when the team is busy maintaining what exists and can't build the new thing, or when the discovery and design step is missing. We deliver alongside your team, not over it.

Yes. Code, data and access stay in your name, on your infrastructure. We don't lock clients in through technical dependency.

You can take it over with your team, because we document it for exactly that, or leave it in our care, with fixes, monitoring and new features in defined cycles.

We do, in our production: discovery, code, testing and QA. That is what lets a lean team deliver fast. But what you are buying is a working product, not the technology we use to build it.

Start with a diagnosis.

Tell us how your operation works today. We'll come back with a read on what software can solve and what isn't worth building.

Book a diagnosis