Hidden cost of running design projects without single source of truth

The Hidden Cost of Running Design Projects Without a Single Source of Truth

29 July 2026

Most architecture projects don’t fail because of one bad decision. They fail because the same decision exists in three different versions, and nobody can say which one is current. A client approves a material substitution in a text message. A budget gets updated in one person’s spreadsheet but not another’s. A floor plan revision gets buried in a two-week-old email thread. None of these is a disaster on its own. Together, they describe a project running without a single source of truth, and every symptom downstream, disputed approvals, drifting budgets, scope creep, traces back to that one root cause.

According to the Project Management Institute’s Pulse of the Profession research, 52 percent of projects across industries now experience scope creep, up from 43 percent just a few years earlier. Architecture is no exception. A client asks for “just one more option” during design development, a stakeholder requests “a quick revision” over email, and by the time a project reaches handover, nobody can say for certain which version was actually approved, or when.

The mechanism behind this is not complicated. A decision without a single, agreed record is not really a decision, it is a conversation that can be reinterpreted the moment there is a disagreement about cost, timeline, or scope. The studios that keep this under control tend to share one habit: every decision, however small, gets a timestamp and exactly one fixed home, rather than living in whichever channel happened to carry the conversation that day.

This is not a communication problem in the usual sense. It is a documentation problem wearing a communication costume. A studio can have excellent client relationships and still lose control of a project simply because the project’s data lives in five different places: an email thread, a text message, a marked-up PDF, a spreadsheet, and someone’s memory of a phone call, rather than in one project system of record. In practice, a project with a genuine single source of truth comes down to four rules, what we’ll call here the Four Principles of a Single Source of Truth.

A project has exactly one current truth. Every approved decision, every specification, every price has one place where its current version lives. Emails and calls are the conversation around a decision, not the record of it. This is the principle everything else in this piece follows from.
A decision without a timestamp is not a decision. Until something has a recorded date and format, it cannot be reliably reconstructed later, which is exactly when it tends to be disputed.
If the client has to ask for a status update, the single source of truth has already failed. A well-designed workflow reaches the client before the client has to reach out.
A budget or specification is a byproduct of the single source of truth, not a separate document. It should follow directly from what has been signed off, not require manual reconciliation against a parallel file.

Client approval disputes are simply the most visible symptom of a project that lacks this. The rest of this piece walks through where the underlying fragmentation actually originates, what these four principles look like in practice at each stage of a project, and a short comparison of the tools studios use to build one.

Why Email Threads and Shared Drives Quietly Fail

On a single small project, tracking everything by email is manageable. The trouble starts once a studio is running three or four projects in parallel. A client approves a material substitution in a text message. A revision to the floor plan gets buried in a two-week-old email thread. A contractor confirms a lead time over the phone, so nobody has it in writing. Each of these on its own is minor. Together, they are the same underlying problem showing up in different forms: there is no single place where the current state of the project lives, so every decision has to be reconstructed rather than simply looked up.

The most common consequences of an undocumented process: a client verbally approves something and later disputes it; a budget quietly drifts because a substitution was never logged against the original spec; the project lead spends time rebuilding a decision history instead of doing design work. The more channels a studio uses with a given client, at once, the higher the odds that two people will remember two different versions of the same conversation.

A typical fragmented process lives simultaneously in four places: an inbox, a messaging app, a shared drive full of PDFs, and a spreadsheet tracking cost. Every additional location is another point where the record can drift from reality.

The real cost of an undocumented process is rarely one catastrophic mistake. It is the accumulation of small ones: five minutes searching an inbox, ten minutes trying to remember what was agreed last week, fifteen minutes reconstructing which version of a drawing is current. Across several active projects, that adds up to real hours every single week.

The table below is a quick way to spot where a process has already slipped out of control:

If…	It’s a sign that…
You’re searching email to confirm who approved a change, and when	Approvals don’t have one shared home
You’re manually recalculating a budget after every substitution	The spreadsheet has stopped keeping pace with the project
A client asks for a status update because they genuinely don’t know where things stand	There’s no single place the client can check without asking
Nobody can say which version of a drawing or spec is current	Revisions aren’t clearly versioned or labelled
You have to call a supplier to remind yourself of a quoted price	Product data wasn’t recorded at the point it was found

There are broadly three ways studios handle this today: spreadsheets and messaging apps stitched together manually, general-purpose project tools (Notion, Trello, Asana, Monday) adapted to fit design work, and software built specifically around a single, consolidated project record. The differences between these three show up at every stage below.

Stage 1: Intake and Brief (Where the Single Source of Truth Starts)

A solid brief is more than a client wish list. It is the reference point the whole team returns to whenever there is a dispute about scope. A useful brief captures the budget range, the timeline, reference material (photos, precedents, prior work the client liked), site constraints, and, critically, who is actually authorized to approve changes if there is more than one decision-maker involved.

The practical rule: a client should be able to submit a brief or intake questionnaire without creating an account or installing anything, through a single link. The higher the friction at the very start, the more likely the client defaults back to a phone call or a string of texts, and the process fragments from day one. The questionnaire itself is usually a one-time tool: the client fills it in once, and the project lead retains a permanent reference to the answers throughout the project, even though the client themselves rarely revisits it.

A simple test for whether a brief is good enough: does it answer “who specifically approves changes” without requiring you to go back and ask later? If you have to ask after the fact, the brief was incomplete from the start.

At this stage, software built for design practices typically offers a ready-made intake form that feeds directly into the project record, rather than a Word document or a generic form tool whose answers then have to be copied over by hand. Some modern design practice platforms, including Planify, approach the entire brief this way: a single form whose answers become part of the project’s one current record from day one, rather than a document that sits separately from everything that follows.

Stage 2: Concept Development and Visual Feedback

Concept and moodboard review is where misunderstandings happen most often. The client is looking at one version, the designer has already moved on to the next, and revision notes pile up across a stack of marked-up PDFs. A comment like “something about the third image” requires a follow-up just to identify what “something” means.

What helps is the ability to leave a comment pinned to an exact point on a specific image, rather than describing the location in words. In practice, a project rarely produces a single moodboard, more often it is several files: separate boards per room or system, or successive rounds of the same concept. What matters is not forcing everything into one file, it is keeping every version in one place the client can access, with comments attached to the specific file and the specific point on the image, rather than scattered across email threads.

Both general visual tools (Figma, Pinterest boards, shared drives) and moodboard modules built into design-project software can work here. The advantage of the latter is that client comments and pins stay attached to the file inside the project record, rather than getting lost in a separate email thread that has to be tracked down later.

Stage 3: Specification and Budget (Rule 4: the budget as a byproduct of the single source of truth)

This is where budget control is most commonly lost. Every specified item, whether it’s a material, a fixture, or a piece of furniture, has a price, a supplier, a lead time, and an approval status, and once a project reaches dozens of line items, a spreadsheet starts to fall behind, especially the moment a client asks to swap one item for another mid-project.

A project budget should not be a document created once and edited from memory afterward. It should function as a live dataset: a status or price change on one line item should be reflected in the internal budget immediately, rather than requiring a manual recalculation somewhere else. The client-facing document, whether that’s called a proposal or a cost summary, is still something the project lead prepares and sends manually, but it draws on data that is always current, rather than being rebuilt by hand each time.

Some newer tools speed up specification entry two ways: a project lead can paste a product link from a supplier’s site and have the system pull in the name, price, and image automatically, or use a browser extension to save a product directly to a project, a favorites library, or a mood collection while browsing a supplier’s site, rather than switching to a separate app to log it. Manually transcribing a single product into a spreadsheet, by contrast, typically takes a couple of minutes once name, price, image link and supplier details are accounted for, which adds up quickly across a list of fifty or more items.

The signal that a spreadsheet has stopped scaling: a project lead has to check several tabs manually to answer a simple client question like “what does the project total now, after that change.” If getting the current total requires manual reconciliation rather than a single glance at the line items, the spreadsheet has stopped keeping pace with the project.

The deeper issue with a fragmented process is not any single change, it’s that every change multiplies across however many places the data lives separately. One product substitution in a fragmented process, spreadsheet, a confirmation email to the client, a note to a supplier or contractor, typically means three separate manual updates, each of which has to be checked for consistency on its own. On a project with several dozen specified items and half a dozen substitutions over the course of the build, that is a dozen or more separate updates instead of one change that everyone involved sees automatically. That is the cascading cost of not having a single source of truth: the cost of disorganization scales not with the number of changes, but with the number of changes multiplied by the number of places each one has to be recorded.

A well-maintained specification list should carry more than just a price for every line:

List item	Why it matters
Name, image, and description	The client knows exactly what they’re approving, without searching a separate catalogue
Supplier and product link	Fast reference point for a warranty claim or a repeat order
Price	The basis for the running budget
Dimensions, finish, SKU	Data the project lead needs for the spec and the order, optional to surface to the client at the point of approval depending on how much detail a given studio wants to expose
Status (pending, sent for approval, approved, ordered, delivered)	Clear information for both sides without anyone having to ask
Approval date	Documentation of the client’s decision, useful if a dispute or a warranty issue comes up later

What a client sees at the point of approval can be as light as an image, a short description, a price, and a link, or can include the fuller technical detail, depending on what the project lead chooses to expose for that item.

Stage 4: The Client Portal (Rules 2 and 3: where the single source of truth becomes visible to the client)

A verbal “yes, go ahead, love it” protects nobody, not the designer, not the client. The status of every specified item should be reconstructable without asking the project lead, meaning what was approved and when, recorded in one place rather than in two people’s memories. This is not about adding bureaucracy to the relationship, it’s about making sure that three months later, when someone asks why a particular choice was made, the answer is easy to find.

It also helps to reduce the number of communication channels down to one place the client can reach without creating an account, for example through a link with an access code rather than a password to remember. The less friction on the client’s side, the more likely they actually use that one place, instead of defaulting back to email or a messaging app. A well-designed client portal should function simultaneously as the place for communication, approval, and documentation: the client opens the link, sees the current state of the project, and can approve or comment on a specific item, with every action timestamped.

A client who has to create an account and remember a password to check their project’s status will, in practice, not do it a second time. They’ll default to the path of least resistance, which is a message to the project lead, and the record starts fragmenting across channels again.

A well-designed client portal is more than a place to approve products. Worth consolidating in one location: items awaiting approval, inspiration and moodboards collected as the project develops, a timeline showing the current phase, project documents (contracts, specifications, drawings, cost proposals shared as they’re prepared), and contact details for everyone involved, so the client has a full picture of progress without asking. Scattering these across email, a shared drive, and a messaging app is the most common reason a client and a project lead end up with two different mental models of where a project actually stands.

Relatively few tools on the market currently combine all of this in one place without requiring the client to create an account. Planify is one example: the client receives a single link with an access code, opens it in a browser, and sees the items awaiting approval, moodboards, the project timeline, documents, and any cost proposals the project lead has shared, without installing anything or setting up an account. The running budget itself stays on the project lead’s side as a live, continuously updated internal view, the client sees it in the form of whatever proposal or cost summary gets shared with them, not as a separate live budget tab of their own.

Hugo Fleming, Design Director at the UK studio Cranberryhome, summed up working this way after a few months: “One of the best, most comprehensive and intuitive platforms I’ve seen, it adds a genuinely professional dimension to our offering.”

Stage 5: Closeout and Handover

At project close, a client should have a clear picture of what they paid for: a final itemized summary with pricing, a record of any changes along the way, and confirmation of delivery. This is also the point to leave the client with lasting access to project documentation, useful for a future warranty claim or the next project a year or two down the line. This is a closeout stage, not bookkeeping or financial reconciliation, that still sits with the project lead outside any given tool, usually through a separate accounting system or an accountant.

Well-built design-project software lets the project lead assemble a final summary (sometimes called a proposal or financial summary) directly from the approved line items, rather than manually re-entering data scattered across several places. The document that reaches the client is still something the project lead prepares and sends, the difference is how much manual work goes into producing it.

What Not to Do

Regardless of a studio’s size, a handful of habits reliably break a single source of truth before it ever gets established:

keeping multiple parallel versions of a budget instead of one current file,
collecting client approvals over text or a messaging app without logging them anywhere else,
accepting design changes over the phone without written confirmation,
naming files “budget_v17_FINAL_FINAL_v2”, which makes it functionally impossible to tell which version is actually current.

None of these habits is a failure on its own. The problem is the accumulation: every additional channel or version is one more place where the project’s single current truth can quietly split into two.

Comparing Approaches in Practice

Not every studio needs dedicated software. For a single, straightforward project, a well-organized folder and a spreadsheet are entirely sufficient. The problem shows up at scale, several projects running in parallel, a specification list with dozens of line items, and clients who expect a fast answer when they ask for a status update.

Three approaches show up repeatedly in practice, and who each one suits:

Approach	What it looks like	Works well when	Biggest risk
Email + spreadsheet + messaging app	Budget in a spreadsheet, moodboard in PDFs, decisions in messages	A single, straightforward project at a time	Decisions scattered across channels, manual budget recalculation
General-purpose tools (Notion, Trello, Asana)	A structure built manually to fit design work	A team that already knows the tool from other areas of the practice	No native link between the budget, the spec list, and client approvals
Software built for design practices (e.g. Planify)	Ready-made structure: moodboards and spec list on the project lead’s side, an approval and status portal on the client’s side	Several parallel projects, a large specification list, clients expecting a current status	Less flexibility outside project and client management specifically

The difference between a general-purpose tool and one built for design practice work rarely comes down to one being “better.” It comes down to who builds the logic connecting the budget, the spec list, and client approvals: in a general-purpose tool, the project lead builds that manually; in dedicated software, that logic already exists.

The choice depends on the scale of the practice and how many projects run in parallel at once. It’s worth pairing this with the broader question of tooling, covered in e-architect’s guide to top project management software for architects, before committing to rolling any single system out across a practice.

There is no single correct process. Every practice works differently, at a different scale, with a different client base. Regardless of team size, though, a genuine single source of truth rests on the same four rules: one current truth, a traceable decision, staying ahead of client questions, and a budget that follows from that record rather than from a document maintained by hand. Approval disputes, budget drift, and lost revisions are simply what it looks like when one of those four rules is missing.

Modern design practice platforms such as Planify have been designed around this idea from the outset, a single source of truth, rather than a set of disconnected project files bolted together after the fact. Whether that single source of truth is built internally through disciplined habits or through dedicated software matters less than making sure every decision has exactly one permanent home.

Every design project eventually ends up with a single source of truth. The only question is whether a studio creates it deliberately, or spends months reconstructing it after the fact.

Checklist: Does Your Project Have a Real Single Source of Truth?

Five quick questions that show how close a project is to having one current, reliable record:

Does the client have one place to approve items and decisions?
Does every specified item carry a clear, current status?
Does the budget reflect the current state of every item immediately, without manual recalculation across several places, before it reaches the client?
Are project documents (contract, specification, drawings) kept in one place, rather than split between email and a shared drive?
Is the status and approval date of every item recorded in a system, rather than only remembered?

Score yourself on how many you can answer “yes” to. 0-2 means there’s no real single source of truth yet, probably starting with the place where a client approves decisions. 3-4 is a solid, working record with one or two weak points. 5 suggests a mature workflow where the project genuinely has one current truth, and most of the chaos described in this piece has already been designed out.

FAQ

Is a spreadsheet good enough for managing a design project?

For a single, straightforward project, yes, it’s entirely sufficient. The problem shows up with several parallel projects and a large specification list, where manually recalculating a budget after every change becomes time-consuming and error-prone.

How do you avoid disputes with a client over project scope?

A detailed brief at the outset, plus a recorded trail for every material decision, who approved what, and when. Ideally kept in one place, rather than scattered across email, phone calls, and messaging apps.

Does a client need to create an account to track project progress?

Not necessarily. Some tools let a client access their project through a link with a code, without setting up an account or a password. That lowers the barrier to actually using it.

What should a specification list and budget include?

Product name, image, supplier, product link, price, dimensions, and client approval status. Across dozens of items, it’s worth having a change to one line reflect immediately in the overall project budget, rather than requiring a manual recalculation.

What’s the practical difference between general-purpose tools and software built for design practices?

A general-purpose tool, like Notion or Trello, requires building the structure connecting the budget, the spec list, and client approvals from scratch. Dedicated software, like Planify, has that structure ready from day one, at the cost of less flexibility outside project and client management specifically.

Does dedicated project software make sense for a solo practitioner?

Yes, once the number of parallel projects or the complexity of the specification list starts outgrowing a spreadsheet. For a single, simple project, general-purpose tools are entirely sufficient.

Does a client see every change to a project as it happens?

It depends on the approach. In a no-login client portal, the client sees the current status of every item (pending, sent for approval, approved, ordered) without needing to ask the project lead. With communication scattered across email and messaging apps, a client typically only knows the state of things as of the last message, not the current state.

What happens when a client changes their mind after approving something?

A status change (say, from approved to rejected after a change of mind) should be logged with a new date, rather than only communicated verbally. That way, it’s always clear what the current state of an item is and since when, which matters when reconciling a cost difference between the client and the project lead.

Comments on this guide to Hidden cost of running design projects without single source of truth article are welcome.