Planner: from specification to app

Planner is our own tool that turns detailed specifications into an application without supervision. For every feature the test is written first, the result is checked in the browser against the design, and a quality gate decides what moves on.

Our own product

Industry	Internal tools & platforms
Challenge	Unclear structure
Decision environment	Product evaluation
Complexity	High
Service	Platform

If you wonder what kind of checking it takes to get an application out of a written specification, this case study shows how Planner works from the first line to delivery, and where the final decision always stays: with you. Planner is our own tool, so we give its real name.

Item	Detail
Kind	Our own product, with a name
Input	Written specifications and the client's material
Two kinds of projects	Website (Next.js with our own CMS) and SaaS platform (Laravel API and Next.js)
Rule for every feature	Test first, then code
Services it supports	Business websites, SaaS platforms and business applications

Planner: from specification to app What was the starting point?

We build websites and platforms for organisations that want a predictable result. The same basic steps repeat in every project: setup, features, tests, a check of how it looks, fixes. When they are done from memory, they change a little from project to project. A fixed tool makes sure every step is always done the same way.

That is why we turned our method into a tool. Planner takes specifications and follows the same path every time. It is not a template that produces identical sites. It is a process that completes every step.

It works on two kinds of projects: a website in Next.js with our own CMS as the backend, and a SaaS platform with a Laravel API and Next.js.

Planner: from specification to app What did Planner have to solve?

The main need was consistency as the volume grows. Specifications are one long document. Somewhere between page 3 and page 40, a requirement can be built a little differently, forgotten, or break something else. A person catches some of these, a tired person fewer.

There was a second need. An automatic job with no one watching can drift away from its goal for hours. A tool that runs unsupervised needs a supervisor and fixed limits, so that autonomy always comes with checking.

Planner: from specification to app What limits shaped it?

Four limits came from the way we work. The owner of the project decides what only the owner can decide. The tool finishes its work, with no endless loops. The limits are written in the code. The client's facts are never invented. The details follow.

The limits are written in the code: at most 5 sessions per task, 3 repairs of the quality gate, 3 attempts per round of checks. When a limit is reached, the issue is left for the owner, while the run continues with the rest.

The last limit is about content. Prices, approvals or facts come from the client. Whatever only the owner can provide is collected in one list for the owner, and the text is written so that it reads as complete without them.

Planner: from specification to app What makes an automatic build reliable?

An automatic build becomes reliable when it covers three points. Every success is proven by code that has really run. Every fix is followed by a new check of everything else, so that nothing else breaks. Every attempt has a limit, so the tool does not fix the same thing again and again.

There is a fourth point: the page in the browser must look like the agreed design. The comparison happens for every feature, not only at the end. So a deviation is fixed at once, before it repeats across many pages.
Each of these points became a rule of Planner. The next sections show how.

Planner: from specification to app What is the approach?

Planner follows a fixed path, from the plan to the reports. Every feature goes through the same steps: a failing test, code, quality gate, browser check, independent re-check. The numbered list below shows the order, from the specifications to the final quality and security checks.

Plan: the specifications become a list of features with acceptance criteria and pages.
Content: every page and every article is written before it is built.
For every feature: first an impact analysis, then a failing test, then the code that makes it pass, and finally tidying up.
Quality gate: lint, typecheck, tests, build and e2e tests must pass, with proof.
Browser check: the result is opened and compared with the design.
Independent re-check of the feature and a commit.
The owner sees and approves the build before the checks start. From there on the design is locked: changes of look become suggestions to the owner.
Checks: the quality and security agents run on a fixed path. We describe them in the case study Quality and security agents.

Two levels watch over the work. A hook inside the session does not let it stop without proof. A supervisor outside the session starts it again, waits when the usage limits run out, and keeps the phases and limits. When there is a real obstacle, it passes it to a judge who decides how the work continues.

Planner: from specification to app What were the key decisions?

There are six key decisions: the test first, proof instead of claims, a fixed path with fixed rounds, owner approval before the checks, tests on a copy of the database, and a CMS that is read-only. Each answers one of the points in the previous section.

Test first

For every feature the failing test is written first. So "done" is clearly defined from the start.

Proof, not a claim

The gate runs real commands and keeps the result. A feature counts as done only when the checks prove it.

Fixed path, fixed rounds

Each checking agent runs once, in a fixed order and for a set number of rounds. The second round runs only if the first one fixed something. An agent runs again only within its own sequence, not because someone else changed code. This way the process always finishes.

The owner approves before the checks

At this point the design is locked. The checks focus on correctness, not on taste.

Tests on a copy of the database

The tests run on a copy, never on the content database. The tool stops if the two databases are the same, so the real content stays free of test data.

The CMS is read-only on the site

Whatever is found inside the CMS is recorded and fixed in its own repository, not by a quick change inside a single site.

Planner: from specification to app What is the result?

The result is consistency. Every project follows the same path and every step leaves proof behind, so nothing depends on someone's attention.

The client gets a build where every feature has a test and every page has been checked in a browser. The client also gets a file of what was checked, with a short list of the decisions that were theirs. So the site rests on a path that can be checked, not on someone's memory, and stays reliable for years.

Planner takes over the repeated parts of the work, so that human judgement can focus on the questions that need it. To see how a project moves from the request to delivery, read about our process or start a project.

Planner: from specification to app Frequently asked questions

Does Planner need human involvement?

Yes, for the decisions that belong to the owner. Planner works unsupervised in between. The owner approves the build before the checks and decides what only the owner can. Planner collects these issues in a list and continues with the rest.

What does "test first" mean for the client?

It means every feature has an automatic check, written before the feature itself. If a later change affects it, the check catches it at once. So we find the problems, before you meet them.

Which technologies does Planner work with?

It works on two kinds of projects: websites in Next.js with our own CMS, and SaaS platforms with a Laravel API and Next.js. For other technologies, we discuss it with you before the project starts.

Next step: Planner: from specification to app

Start your project

Send a project request, or check your current website for free. We read every message ourselves.

Start a project Check your website