aeternum
Let's talk

03 / what we do

Product development, from discovery to the second release.

A small team that takes a product from an unproven idea to something with paying users, and then keeps it running.

what's included

Scope is the only lever that reliably moves a deadline.

  • Discovery
  • MVP Build
  • Platform Architecture
  • Long-term Maintenance

What we do here

Aeternum takes a product from an idea somebody has argued for to a system that real users pay for. Two engineers do the whole path: discovery, build, architecture, and the maintenance afterwards. Nothing is handed to a different team at any point.

The order matters more than the speed. Most failed products were built correctly and aimed wrong.

We run our own product

DriveFlow is our SaaS for Swiss driving schools: booking, the training record, billing and school administration in one app. We built it, we run it, and it is going into pilot with real schools.

That matters here for one reason. Every architectural shortcut we might recommend to you, we have already paid for ourselves on a system we cannot walk away from.

How we estimate

We quote ranges, not points, and we tell you which end of the range we expect. The width of the range is itself information: a wide one means the brief has an unanswered question in it, and the fastest way to narrow it is usually a day of prototyping rather than another meeting.

Anything we cannot estimate honestly, we say we cannot estimate, and we propose a spike to find out.

Maintenance is part of the build

A product that ships without a maintenance plan gets one anyway, usually at the worst moment. We agree upfront who is paged, how fast, and what a fix costs. Dependency updates run monthly. You get a written note of what changed, in language you can forward to a client.

how a build runs

How a build runs

  1. Discovery

    We map the workflow the product replaces, name the one job it must do better than the status quo, and cut everything that is not that job. The output is a scope, a rough plan, and an honest opinion on whether to build it at all.

  2. MVP build

    The narrowest version that a real user can pay for. Auth, billing and deployment are in from the first week, because retrofitting them is the classic reason a prototype cannot become a product.

  3. Platform architecture

    Once the shape is proven, the parts that were deliberately naive get rebuilt: data model, background jobs, permissions, tenancy. This happens with users on the system, not before them.

  4. Long-term maintenance

    Dependency updates, incident response, and the same two people who built it, so nobody has to relearn the codebase.

questions

Questions about Product Development.

What is the smallest useful engagement?

A scoping round before anything is built. It ends with a scope and an estimate, and an honest opinion on whether to build it at all. We would rather lose the build than start one on a brief nobody has tested.

Do you build MVPs or production systems?

Both, and the distinction matters less than people think. We put auth, billing and deploys in from week one even on an MVP, because those three are what stop a prototype from becoming a product.

Have you shipped a product of your own?

Yes. DriveFlow is our own SaaS for Swiss driving schools, built and run by the two of us and now going into pilot. We still run it, which means we carry the maintenance and the support calls that our own architecture decisions produce.

What happens if the deadline is fixed?

Then the scope moves, because it is the only lever that reliably does. We will show you which parts can be cut, what each one buys back in time, and what the cut costs the user. Adding people to a late two-person project makes it later.

posts on this

Posts on this

  1. What we check before a real business uses itProduct5 min read
All posts

Tell us what you want to build.

Send the brief. You get a scope and a range within two working days.

other services

Other services