AI by product phase · Design

Validating on screen is cheaper than in code.

We design the architecture, the data model and the flows before writing product. AI generates variants fast; judgement decides which one survives real use.

Where it hurts

Decisions you pay for later.

01

An improvised data model.

What you save at the start you pay in every later migration.

02

Unvalidated flows.

Beautiful screens nobody uses because they do not fit the real work.

03

Oversized architecture.

Infrastructure for a scale that does not exist, with the cost that drags along.

What we do here

Four concrete deliveries.

The design is validated with the people who will use it, in their context, before any production code exists.

  1. 01

    Technical architecture

    Stack, services, integrations and deployment. Sized to your real scale.

  2. 02

    Data model

    Entities, relationships and traceability. Designed for the reporting you will ask for later.

  3. 03

    Navigable prototype

    Clickable flows to validate with real users before building.

  4. 04

    Documented decisions

    Every technical choice with its reason. The next team understands why.

What you get
How it applies here · No case of our own yet

What we bring from what is already running.

The case of our own here is Squlp: a game-economy data model that withstands simulations no spreadsheet can take, and which exists because it was designed before any product was written. Smart Build is the useful opposite: the work-package structure had to be modelled properly from the start because changing it with live sites inside was not an option. The data model is the most expensive decision to reverse.

Highest-impact use cases

  1. 01

    The data model before the screen

    Entities, relationships and what is the source of truth for what. It decides whether in two years a new question can be answered or everything has to be migrated.

    The most expensive decision to reverse is taken first.

  2. 02

    Architecture the size of the problem

    Neither a monolith nobody can touch nor twenty services for three screens. It is sized by the real load and by who will maintain it.

    Avoids paying for complexity nobody needs.

  3. 03

    Navigable prototype before the code

    Flows are tested with the people who will actually do the work. Changing a screen in the prototype costs an afternoon; changing it in production costs weeks.

    The mistake surfaces while it is still cheap.

  4. 04

    Decisions documented with their reasoning

    Why this database and not the other, what was ruled out and under which assumption. When the assumption changes, you will know what to revisit.

    Stops the same argument reopening every year.

See the products that are in production
Services involved

What it is built with.

Related reading

Before you call us, read this.

  1. Guide · 9 min

    How long does it take to develop an app or custom software? Real timelines by project type

    An MVP in weeks, an internal app in months, a SaaS in half a year or more. The question "when will I have it?" has honest answers if you understand what moves the schedule. These are the real timelines for custom software and the factors that genuinely stretch or shorten them.

  2. Guide · 9 min

    9 mistakes when hiring custom software development (and how to avoid them)

    Custom builds go wrong for almost always the same reasons: choosing on price, not insisting on owning the code, going in with vague requirements. These are the 9 most expensive mistakes and the concrete questions to avoid each one before signing.

More in AI by product phase
First step, no strings attached

Not sure where to start? Measure your organisation’s AI maturity for free in 3 minutes, or book 30 minutes of direct diagnostic.

Let's start

Let's talk about your operation.

Tell us what costs more than it should. We come back with a concrete plan, realistic timelines and a clear yes or no.

contacto@plantekia.com