"Let's start coding, we'll figure out the details as we go." This is probably the most expensive sentence in the digital industry. At CodingArt, we've seen too many projects land on our desk after a first provider who said yes to everything without writing anything down — result: €60,000 spent, six months late, zero deliverable line. Specifications and technical requirements are not paperwork. They are the spine that determines whether your project finishes at €12,000 or €80,000.
TL;DR: 2 to 5 days spent writing a serious spec save 20 to 40% of the total project budget and divide the litigation risk by 3. If your provider refuses to write one, run away.
Specifications vs technical requirements: don't confuse them
Many SMEs confuse the two documents. They are however distinct, complementary tools, each with a different target audience.
| Document | Audience | Content | When |
|---|---|---|---|
| Spec / RFP | Leadership, business, provider | WHAT to do and WHY: objectives, scope, constraints, deliverables, budget | BEFORE the quote |
| Technical specs | Dev team, tech lead, QA | HOW to do it: architecture, data models, API, stack, security | AFTER signing, BEFORE code |
| User stories | Product owner, dev, designer | User behavior: "As X I want Y so that Z" | During the sprint |
The spec doc is a moral contract between you and your provider: it freezes the scope and provides a discussion basis in case of disagreement. The tech specs are an implementation guide for developers: they prevent everyone from interpreting the need differently.
The 5 risks that explode without a spec doc
- Scope creep: without a written boundary, every meeting adds "just one small feature" — and the budget blows up by 40 to 200%.
- Incomparable quotes: 3 agencies contacted without a common spec = 3 quotes based on 3 different assumptions. You're comparing apples and oranges.
- Legal dispute at handover: "I wanted this" vs "you never said that" — without signed spec, the judge decides on feeling.
- Costly redevelopment: 3 months after launch, you realize a critical use case was never considered. Cost: 2 to 5x the initial cost to add it post-prod.
- Team demotivation: developers frustrated by redoing the same feature 5 times because expectations float — turnover increases, quality collapses.
Field statistic: out of 30+ recovery projects we led at CodingArt in 2024-2026, 28 had been launched WITHOUT a written spec. The other 2 had a vague 4-page spec, outdated within 2 sprints.
What a good spec document should contain
An effective spec doesn't need to be an 80-page brick. For an SME project (€5,000 to €50,000), 8 to 15 well-written pages are largely sufficient. Here's the structure we recommend to our clients and that covers 95% of web/mobile projects.
1. Context & objectives
Who you are (activity, size), what business problem the project seeks to solve, what are the measurable success indicators (e.g., "increase online sales by 30% in 12 months"). Without this section, the provider designs in a vacuum.
2. User targets
Personas (2 to 4 max), digital maturity level, devices used (mobile-first or desktop?), accessibility constraints (WCAG?), required languages.
3. Functional scope
Exhaustive list of expected features, classified as "must-have" (MVP), "should-have" (V1.1), "could-have" (V2). This is the most critical point: what's not written here is not in the quote.
4. Content & branding
Who provides texts, photos, videos? Is there an existing brand identity? If not, should the agency create one (count €2,000 to €8,000 extra)?
5. Technical constraints
Mandatory hosting (GDPR? HDS? EU sovereignty?), required stack (legacy IS), third-party integrations (CRM, ERP, payment, mobile money), SEO requirements, expected performance (Lighthouse 90+? Core Web Vitals green?).
6. Planning & budget
Desired launch date (and why: event, season, legal constraint?), approximate budget (don't lie — a hidden budget always leads to an off-topic quote), payment terms (schedule, deposits).
7. Acceptance criteria & warranty
What tests validate delivery? How many fix cycles are included? What warranty period (30, 60, 90 days)? What happens if a critical bug occurs post-launch?
What a good technical specs document should contain
Technical specs are written by the development team AFTER spec validation, before the first line of code. They transform the "WHAT" into the "HOW". On a typical web project, count 5 to 20 pages.
- Software architecture: monolith vs microservices, separated front/back, tech choices justified.
- Data models: database schema, relationships, critical indexes, integrity constraints.
- API contracts: endpoints, payloads, error codes, authentication (JWT, OAuth, session?), rate limiting.
- Security: where secrets are stored, encryption at rest and in transit, session management, anti-CSRF/XSS, leak plan.
- Hosting & deployment: datacenters, horizontal/vertical scaling, CDN, backup (RPO/RTO), monitoring.
- Test strategy: unit, integration, E2E, load, accessibility — what coverage target (60%, 80%?).
- Production rollout plan: feature flags, blue-green / canary, automatic rollback on anomaly.
- Documentation: where and how it's maintained (Notion, Confluence, README in repo?).
CodingArt tip: we provide every client a free spec template adapted to their industry (e-commerce, B2B SaaS, mobile app, etc.) during the first call. It saves you 2-3 days of writing.
The 7 most common mistakes
- Confusing spec with commercial brief: a 2-page sales brief doesn't count as spec.
- Listing 200 features without prioritization: if everything is P0, nothing is P0. Maximum 15 "must-have" features for an MVP.
- Forgetting error flows: "what does the user do when payment fails?" — rarely written answer, source of 30% of production bugs.
- No wireframes: describing a user journey without wireframe means asking for 3 different interpretations.
- Secret budget: refusing to give a range always leads to an oversized or undersized quote, never aligned.
- No measurable criteria: "the site must be fast" means nothing. "Lighthouse 90+ on home, LCP < 2s" is a measurable criterion.
- Not having the spec reviewed by an independent tech: a lawyer reviews a contract, a doctor reviews a prescription — your spec deserves a neutral review by an external CTO (€200-500, huge return on investment).
How much does writing a serious spec cost?
Three options are available depending on your maturity and available time.
| Option | Cost | Time | For whom |
|---|---|---|---|
| You write it alone from a template | €0 | 5 to 10 days | Leader who has already managed an IT project |
| Scoping workshop with the agency | €1,500 – €4,500 | 2 to 5 days | SME without internal CTO |
| Independent external consultant | €3,000 – €12,000 | 1 to 3 weeks | Project > €50K or strategic stake |
« The time spent on the spec is the only time that really makes money on a digital project. All the rest is execution. »
How CodingArt supports clients on this step
Even before signing a quote, we offer 1 free scoping workshop (1h30 via video or in-person in Agadir). We come out with a synthesis page that validates or not the relevance of going further. If we continue, we build together a spec in maximum 2 weeks, and our tech leads write the technical specs in parallel starting from signature. Result: no bad surprise after the first sprint, and a delivery deadline kept on 92% of our 2024-2026 projects.
You have a project in mind but don't know where to start? Book a free scoping workshop. You leave the session with a structured brief you can use, even if you don't end up working with us.
Tags
