Spec-driven development: turning discovery chats into build plans

By Marco Lopes · February 20, 2026 · Business & Culture

Discovery conversations are where a project starts to make sense. We hear what is frustrating, what the business needs to change, and what someone has already tried. We also hear contradictions, assumptions, and solutions proposed before the underlying problem is clear.

That is useful material, but it is not yet a build plan.

At Kordspace, we work remotely across software, AI, Web3, hardware, and design. Moving between those disciplines makes one thing especially clear: shared enthusiasm is not the same as shared understanding. Spec-driven development helps us bridge that gap without turning every project into a documentation exercise.

The aim is simple: make the important decisions explicit before implementation makes them expensive to change.

What we mean by spec-driven development

We use a specification as a shared agreement about what we are building, why it matters, and how we will know it works. It connects discovery to design, implementation, testing, and release.

It is not a promise that nothing will change. It is not a giant document handed from one department to another. And it is not just a detailed prompt for an AI coding tool.

A useful spec describes observable behavior, names constraints, exposes uncertainty, and gives the team enough context to make consistent decisions. Implementation can then proceed in small, reviewable steps.

The difference from a feature list is accountability. “Add team invitations” names a capability. A spec explains who can invite whom, what permissions they receive, what happens when an invitation expires, and which outcomes are outside the current scope.

Start discovery with outcomes, not screens

When a conversation begins with “we need a dashboard,” we should not immediately start listing charts. We first need to understand what decision the dashboard supports and why the current process fails.

We structure discovery around a few questions:

• Who experiences the problem, and in what situation?
• What happens today, including workarounds?
• What should become possible or easier?
• Which constraints are fixed, and which are preferences?
• What evidence would justify releasing, revising, or stopping?

For a remote team, we also need context that might otherwise live in hallway conversations: terminology, existing systems, approval boundaries, and stakeholder availability.

We capture concrete examples wherever possible. A walkthrough of a failed handoff often reveals more than a broad request for “better collaboration.”

With permission, transcripts can help preserve detail. But a transcript is evidence, not a specification. Repetition does not make a requirement important, and a confident suggestion does not make it an approved decision.

Separate facts, assumptions, decisions, and questions

One of the fastest ways to create rework is to write every discovery note as though it carries the same authority.

We prefer four explicit categories:

• Facts: verified information about the current situation.
• Assumptions: beliefs we are temporarily using to move forward.
• Decisions: choices an accountable person has approved.
• Open questions: unresolved issues that could affect scope or implementation.

Each important assumption or question needs an owner and a point by which it must be resolved. “Check authentication later” is not enough if authentication determines the application architecture.

We also retain the reason behind consequential decisions. If we choose a managed service to reduce operational burden, that rationale should remain visible when someone later proposes replacing it.

This small discipline makes asynchronous collaboration easier. We can review the state of a decision without reconstructing several meetings and a chat thread.

Write the smallest spec that supports a decision

The right amount of documentation depends on risk. A small interface adjustment needs less explanation than a payment flow, a firmware update mechanism, or a contract holding assets.

We start with a compact structure:

1. Problem and outcome: what changes, for whom, and why.
2. Scope and non-goals: what this increment includes and deliberately excludes.
3. User flows: the main path, alternative paths, and failure states.
4. Requirements: behavior, permissions, data rules, and relevant quality constraints.
5. Acceptance criteria: observable conditions that demonstrate completion.
6. Dependencies and risks: external systems, unresolved assumptions, and validation work.
7. Delivery and release: implementation slices, reviewers, rollout, and recovery.

We keep the authoritative version somewhere the delivery team can find and maintain. That may be a version-controlled document linked to issues and designs. The tool matters less than having one clear source of truth.

When a requirement changes, the spec, tests, and implementation should change together. Otherwise, documentation becomes historical fiction.

Turn a vague request into testable behavior

Consider a hypothetical discovery request: “We need an AI assistant that answers questions about internal documents.”

That leaves almost every consequential decision open. Which documents? Which employees? What counts as an acceptable answer? What happens when the source material is incomplete?

A first-release specification might say:

Authenticated employees can ask questions against approved documents they are authorized to access. Answers include source references. When retrieved evidence is insufficient, the assistant says it cannot answer from the available material. The first release does not modify documents or perform external actions.

We can then define acceptance criteria such as:

• An employee cannot retrieve content from a restricted document through either an answer or a citation.
• A cited source opens at a location the employee can access.
• Missing evidence produces an explicit limitation rather than an unsupported answer.
• A failed model request leaves the interface usable and provides a retry path.

These are not a complete evaluation strategy, but they expose real work. We now need authorization-aware retrieval, source handling, failure states, and agreed evaluation examples, not merely a chat interface.

Specify quality without hiding behind adjectives

Words such as “fast,” “secure,” “intuitive,” and “scalable” sound reassuring but do not guide implementation on their own.

We replace them with conditions appropriate to the project. For performance, we identify the relevant user action, expected workload, measurement environment, and acceptable response target. For security, we define access boundaries, sensitive data handling, audit needs, and the threat assumptions being addressed.

The same principle applies outside conventional application development. Hardware specifications may need power limits, operating conditions, tolerances, and recovery behavior. Web3 work may need explicit trust assumptions, transaction states, upgrade authority, and handling for delayed or failed transactions.

We do not need to settle every detail during discovery. We do need to mark unresolved constraints as unresolved. A blank space that looks like agreement is more dangerous than an openly stated question.

Give AI clear boundaries and evidence

AI-assisted implementation makes explicit specifications more valuable, not less. Tools can produce plausible code quickly, including code that implements the wrong interpretation very thoroughly.

We treat the spec as the contract for a bounded task. Alongside the requested behavior, we provide relevant repository conventions, allowed dependencies, interface definitions, and verification commands.

We also state what the tool must not do: change unrelated modules, introduce services without approval, weaken authorization, or treat failing tests as something to bypass.

Generated work still needs review. Passing tests is evidence, but not proof that the requirements are complete or that every test is meaningful. We compare the implementation against the intended behavior, inspect sensitive paths, and run appropriate automated checks.

For AI product features, we additionally distinguish deterministic requirements from probabilistic behavior. Access control must be enforced by the system, not entrusted to a model instruction. Answer quality needs representative evaluation cases and a documented way to assess failures.

Choose infrastructure after clarifying constraints

We prefer Google Cloud where it fits, and we also work with AWS and Azure. That preference is a starting point, not a requirement imposed on every project.

The spec should surface the factors that make an infrastructure choice defensible: existing identity systems, data residency obligations, integration dependencies, operational skills, expected workloads, and cost constraints.

For an early release, a managed service may be a better fit than a custom platform. For an established organization, fitting existing governance and deployment practices may matter more than choosing our familiar stack.

We make ownership explicit as well. Who controls the cloud accounts? Who receives billing alerts? Who can deploy, restore data, and rotate credentials? A build plan that stops at “deploy to cloud” has left important delivery work unspecified.

Break the plan into vertical slices

Once the behavior is clear, we translate the spec into increments that demonstrate an end-to-end result.

Rather than completing all database work, then all APIs, then all screens, we look for a thin path through the system. For the hypothetical document assistant, that could be an authenticated employee asking a question against a small approved collection and receiving a sourced response.

Each slice should link back to requirements and include its own verification work. We identify dependencies, review responsibilities, and the evidence needed before expanding scope.

Uncertainty deserves a different kind of task. If a hardware interface or retrieval approach is unproven, we schedule a bounded investigation with a specific question and expected evidence. We do not disguise exploration as predictable feature implementation.

This gives us a more honest plan: some work delivers capability, while some reduces risk.

Make review and change part of the workflow

Before building, we review the spec from business, design, engineering, and operational perspectives. Different readers catch different omissions. A flow can be commercially sensible, technically feasible, and still impossible to support comfortably.

We ask reviewers to challenge meaning, not merely wording. What could two reasonable people interpret differently? Which failure would surprise us in production? Which approval are we assuming?

Changes during delivery are normal. We record what changed, why, and how it affects scope, cost, dependencies, or release readiness. Small clarifications can stay lightweight; changes to trust boundaries or product outcomes deserve explicit approval.

In a remote studio, this is also a culture choice. We make disagreement visible early and give people enough written context to contribute without attending every call.

A short checklist before we build

• Have we named the user problem and intended outcome?
• Are scope, non-goals, permissions, and failure states clear?
• Can we test the acceptance criteria?
• Do unresolved questions have owners and resolution points?
• Are infrastructure, data, and operational responsibilities explicit?
• Can we deliver a small end-to-end slice first?
• Do we know who approves release and how to recover?

The purpose is not to eliminate judgment. It is to make judgment informed and shared. A good spec keeps us aligned while leaving room to learn; a good build plan turns that alignment into verifiable progress.

We welcome projects at the messy discovery stage, not just polished briefs. To turn a conversation into a practical build plan, start a project with us, or explore our related services pages for software, AI, Web3, hardware, and design.