SaaS & digital products

From an idea to a product someone can use.

Custom SaaS development and complete digital products: from defining what should exist to developing the application, the logic, the data, the integrations and the infrastructure needed to put it in the hands of real users.

You can arrive with an idea, a problem or a first version. You don't need the architecture, every feature or the technology figured out.

Tell us the ideaSee products we have built

I want to build a platform to… plan deliveries without phone calls

Who?Operations teamsProblem?Every delivery is coordinated by phoneCore action?Plan and confirm a deliveryValue?Fewer calls, deliveries on time
Conceptual sketch · fictional product

Before building, you have to decide what deserves to exist.

Product work starts before the software: finding the product inside the idea. We don't accept a list of fifty features; we look for the first version worth building.

The idea, as it arrives

I want a platform that helps companies manage their deliveries, with customers, routes, invoicing, chat, reports, a driver app and everything the competition does.

Everything it could do · 16

  • Plan deliveries
  • Confirm deliveries
  • Notify the customer
  • See today's status
  • Optimised routes
  • Driver app
  • Internal chat
  • Invoicing
  • Advanced reports
  • Fleet management
  • ERP integration
  • Customer panel
  • Ratings
  • Multiple languages
  • White label
  • Dynamic pricing

The questions that decide it

01
Who is it for?Operations teams at companies that deliver every day
02
What problem does it solve?Coordinating deliveries by phone, with no shared status
03
What is the core action?Plan a delivery and confirm it
04
Why would someone come back?Because every morning they need to see and close the day
05
What is essential in version one?Plan, confirm, notify and see the status
06
What can wait?Routes, invoicing, reports, a native app
07
Which assumption needs testing first?That a team will swap the phone for the panel

A product isn't everything it could do.It's the minimum it must do extraordinarily well.

Reducing scope isn't cutting corners: it gives the product a clear reason to exist.

The first version doesn't have to do everything. It has to solve something for real.

One fictional product, start to finish. On the right, the same interface gains definition as the story moves on; what isn't visible gets decided too.

The same product, at four moments

  1. 01 · Core journey

    The product is a journey, not a list.

    Sign in, see the day, create a delivery and confirm it. Four steps that solve the problem for real. Everything else is arranged around this journey.

    Route
    1. 01Sign in
    2. 02Today's deliveries
    3. 03New delivery
    4. 04Delivery confirmed
  2. 02 · First version

    Only what the journey needs to work.

    A welcome that sets up the team, a workspace, the main action always within reach, the result and a history. Minimal settings. Nothing decorative.

    Route
    Set up your team and your first delivery zone
    Today's deliveriesNew delivery
    • #2041Confirmed
    • #2042En route
    • #2043Pending

    Delivery confirmed · the customer has been notified

  3. 03 · Product system

    Under every screen there are decisions nobody sees.

    Accounts and permissions, the states a delivery goes through, the rules that prevent confirming without a driver, the data and its history, the operator's tools, the email notifications and the deployment that keeps it running.

    Route
    Today's deliveriesNew delivery
    • #2041Confirmed
    • #2042En route
    • #2043Pending

    Can't confirm without an assigned driver

    • Experience
    • Product logic
    • Data
    • Operations
    • Connections
    • Delivery
  4. 04 · Product in use

    No longer a sketch: someone uses it every morning.

    Version 1.0 is deployed, observed and maintained. From now on the product changes because of what users do, not because of what we imagined.

    Routev1.0In production
    Today's deliveriesNew delivery
    • #2041Confirmed
    • #2042En route
    • #2043Pending

    Delivery confirmed · the customer has been notified

    Users ask to reorder the day → v1.1

Fictional example product · not a client

A website ends when it's published.A product starts there.

A website

  1. Visit
  2. Read
  3. Contact

—

A product

  • Account
  • State
  • Data
  • Actions
  • History
  • Permissions
  • Ongoing use
∞

What a product may need, depending on the case

Switch on the systems your product would need

Not every product needs all of this. Knowing what it does and doesn't is part of the work.

Route · A product
  1. AuthenticationSigning in, recovering access, sessions
  2. Accounts and rolesWho belongs to what and what they can do
  3. Product stateWhere each thing stands
  4. Notifications and emailWhat the product says on its own
  5. Operator toolsWhat the team needs to run it

The user needs a product.The team needs to be able to operate it.

RouteUser view
  • Their workspace
  • Their deliveries
  • Their actions
  • Their history

The product changeswhen real users show up.

Launching isn't finishing. It's the moment assumptions meet people who use the product to get work done. From then on, decisions are made from what we see, not from what we imagined.

  1. v0

    Assumption

    A team would swap the phone for a shared panel.

  2. v1

    First useful product

    Plan, confirm, notify and see the day.

  3. v1.1

    Friction removed

    Reorder the day in one gesture; confirm from the phone.

  4. v1.2

    Behaviour discovered

    Teams use the history to handle claims: export is born.

  5. v2

    The product grows

    Delivery zones, per-team permissions and an API for the ERP.

  1. Ship
  2. Observe
  3. Learn
  4. Improve

The job isn't “add more”. It's making the product better at its purpose: sometimes that means removing, sometimes connecting, sometimes rewriting a rule that no longer describes how people work.

Evolving can mean

  • Removing features
  • Simplifying a flow
  • Adding automation
  • Changing permissions
  • Adjusting the logic
  • Adding integrations
  • Scaling the infrastructure
  • Opening new surfaces

We can keep evolving the software after launch. It's the part of the product that lasts longest.

Two products.Two problems that had nothing in common.

Both exist, both are in use, and they started from opposite points. What they share is what this service offers.

01 · Fivo

Infrastructure becomes a payment product.

An online merchant wants to accept stablecoins without understanding networks. Fivo turns that into a product: an embeddable button, hosted checkout sessions and an API with keys; the customer pays from the network where they hold funds; the infrastructure verifies and moves the money; the merchant sees it in their dashboard.

  • 9mainnet networks
  • USDC + EURCstablecoins
  • 3integration paths
  • 5signed webhook events
See the Fivo case
  1. 01 · MerchantCreates the paymentFrom the dashboard or with a button in their store
  2. 02 · CustomerPaysChooses the stablecoin and the network where they hold funds
  3. 03 · InfrastructureExecutesVerifies on-chain and moves the payment across networks when needed
  4. 04 · MerchantSees the resultState, transaction and receipt without leaving the store
  1. 01Drop a documentExtraction proposes fields under a closed schema and flags what's uncertain
  2. 02An obligation appearsSubscription or invoice with amount, cycle and evidence-based payment state
  3. 03The future is derivedUpcoming charges, renewals and deadlines calculated, not stored

02 · Life Admin

Documents become an administration system.

A person receives invoices, subscriptions, warranties and renewals scattered across email and PDFs. Life Admin understands them, turns them into obligations with a state and calculates what comes next. A product of our own, with AI applied where it helps and an assistant that only reads.

  • 22entities
  • 12server functions
  • 939automated tests
See the Life Admin case
And a third one, different again · Web application · real-time dataMP Monitor — A panel that follows dozens of assets live, scores them with fixed rules and explains every figure in plain language.See it in the projects exhibition

The common part wasn't the technology.It was turning a problem into a product someone can use.

Real screenshots with test data. Figures verified in each product's repository.

You don't need to arrive with the product solved.

The project is a shared table. You bring what only you know; we define together what should exist; we build it and put it into production.

01

You bring

  • The idea
  • The problem
  • The market context
  • The users
  • The business knowledge
02

We define together

  • The product scope
  • The core journey
  • The priorities
  • The constraints
  • The first release
03

We build

  • The experience
  • The software
  • The data
  • The logic
  • The infrastructure
  • Production

What you can arrive with

  • I have an idea but don't know how to structure it.
  • We already have a prototype.
  • We built version one and need to rebuild it properly.
  • We need someone to take over the technical side.
  • We have users and now need to evolve the product.

Four starting points, one journey

  1. IdeaNothing built yet
  2. PrototypeSomething to show, nothing to operate
  3. First versionIt works, but it won't hold
  4. Live productWith users, and with debt

No packages and no fixed timelines: every product enters the journey at the point where it is.

Your product

Tell us what you want to exist.

You can arrive with an idea, a problem, a prototype or a product that's already running. We start by understanding what it should solve, for whom, and which first version is worth building.

Tell us the ideaSee products