--- title: "What's the difference between a project build and ongoing support?" description: "A build has a finish line. Support does not. How the two engagements differ in scope, risk, and what you own at the end, and how to tell which one you need." publishedAt: 2026-07-27 author: Ena Pragma url: https://enapragma.co/blog/project-build-vs-ongoing-support tags: ["software-maintenance", "methodology"] --- ## What's the difference between a project build and ongoing support? A build ends. Support does not. That is the whole difference, and almost every other difference follows from it. A project build is scoped work with a finish line. You agree on what gets made, it gets made, and then it is handed to you. Ongoing support is a standing arrangement: someone stays responsible for the system after it is live, watches it, fixes what breaks, and changes it as your business changes. Most people buying software think they are buying the first one. What they usually need is both, and the mistake is not noticing where one ends. ### Where the two actually diverge **Scope.** A build is defined by a list of things to make. Support is defined by a system to keep working. The first can be finished. The second is measured by whether the thing still runs six months from now. **Risk.** In a build, the risk is that the wrong thing gets made. In support, the risk is that the right thing quietly stops working and nobody notices until a customer does. Those are different problems and they need different attention. **What you own at the end.** After a build, you own the code and the responsibility for it. Whether that is a good outcome depends entirely on whether anyone in your company can pick it up. After a support engagement ends, you should own the code, the documentation, and a written record of what was done and why, so the next person is not starting from zero. **How the relationship changes.** A build rewards speed to the finish line. Support rewards not breaking things. A team optimized for one is not automatically good at the other, which is why the handoff between them is where so many systems fall over. ### The gap that costs the most The expensive moment is not the build and it is not the support. It is the space between them. A build finishes. The team that made it moves on. Nothing is obviously wrong, so nothing gets escalated. Then, months later, a dependency goes stale, or a third party changes an API, or a data problem that has been growing since launch finally surfaces. Now the people who understood the system are gone, and the first thing anyone has to do is figure out what is actually running before they can fix anything. We wrote about that specific failure in [what happens when your developer leaves](/blog/what-happens-when-your-developer-leaves). The pattern is the same whether the person left your payroll or an agency's. That gap is not a scheduling problem. It is a structural one: nobody was accountable for the system in its running state, only for its delivery. ### How to tell which one you need You probably need a **build** if there is something specific that does not exist yet, you can describe what "done" looks like, and you have someone who will own it afterward. You probably need **ongoing support** if software you already depend on is running your operations, no one on your team can confidently change it, and the last few problems took much longer to fix than they should have. You almost certainly need **both** if you are commissioning something new that will become load-bearing. In that case the question to ask before signing anything is simple: who is responsible for this system in month seven, and what happens if they are not available? If nobody can answer that, you have bought a build and assumed support. ### How we handle it Ena Pragma does both, and we do not treat them as separate relationships. We build systems and then keep running them, because the team that made something is the cheapest team to maintain it and the most likely to notice when it starts drifting. When we take over software someone else built, the work starts the same way it does for our own: read what is actually there, check the claims against the live system, write down what we find. That process is described in [how we onboard a maintenance client](/blog/how-we-onboard-a-maintenance-client), and the broader shape of the ongoing engagement is in [software maintenance consulting](/blog/software-maintenance-consulting). The standard we hold ourselves to is the same in both modes: if we cannot produce the receipt, we do not call the work complete. For a build that means verified, documented delivery rather than a demo. For support it means you can see what was checked, what was changed, and why, without taking our word for it. ### The short version Buy a build when you need a thing. Buy support when you need a thing to keep working. If the software is going to run your business, you need the second one whether or not you budgeted for it, and it is much cheaper to arrange before the first person walks out the door than after. One conversation is usually enough to tell which of the two you are actually looking at. [Get in touch](/book)