What a custom software development project looks like, start to finish

Before signing, everyone asks about price and timeline. After signing, the question changes: what happens now, and what do we have to do? This article answers that. It walks through a custom software development project in the order things happen, what your company brings to each phase and which decisions you can't leave to the vendor.

We mean projects that run for several months, touch several areas of the business, have to integrate with what you already use and need someone inside the company to put in hours every week. What to ask before requesting a quote is in what to ask before requesting a software quote, and what to ask the vendor is in questions to ask before hiring a software company. Here we start once the contract is signed.

1. Discovery: the real processes and spreadsheets

The first thing isn't screens. It's your spreadsheets, the emails that get forwarded, the paperwork that changes hands and the exceptions only the people doing the work know about. Good discovery means sitting down with those people, not just with management, because what costs money is usually in the details: the order that gets invoiced in two parts, the customer with special terms, the step someone does by hand because the current system won't allow it.

What your company brings: one point person who knows the business and can make decisions, and access to the people who do each task. Also real examples: invoices, orders and spreadsheets as they are used today. What comes out of it: a map of the processes and a ranked list of what goes into the first version and what waits.

2. The data model: the decisions that are hardest to change

Before building anything, you have to decide what each thing means for your company. Can a customer have several locations? Can an order or a job be split across several legal entities? Does a product have variants, or is each variant its own product? They sound like technical questions, but they are business questions, and changing them once the system holds data is expensive. It's the part of the architecture that shapes everything else. In our case studies we show how these decisions were made on two projects.

What your company brings: clear answers to those questions, thinking about how you'll work two or three years from now, not just today.

3. The first delivery, at two weeks

At two weeks something has to be working. Not everything, but a first piece that uses your vocabulary and your real cases: for example, entering an order the way you do today and seeing it in a list. It does two things. It checks that discovery was understood correctly, and it lets your team start seeing the system as theirs rather than something that will arrive one day.

4. A delivery every two weeks

From there, the project moves in two-week cycles. Each cycle ends with a demo of what already works, and that demo is where you decide what comes next. Priorities can change between cycles: once people see the system, things come up that weren't in discovery. What matters is that each change is decided looking at the whole, not by bolting on pieces.

This phase also covers integrations with what you already have: accounting, the online store, the bank, a supplier's system. Each one is treated as another delivery, with its own test.

What your company brings: attending the demo, testing between demos with real data and setting priorities. This is the part people underestimate most. The point person needs hours every week; without them, the project stalls or, worse, heads in the wrong direction without anyone noticing. What drives the overall timeline is covered in how long a custom ERP takes.

5. Data migration

The data you have today has to move to the new system: customers, products, order history, balances. There are almost always duplicates, fields used for things they weren't meant for and half-filled records. Migration doesn't happen once: it's rehearsed several times, with more complete data each time, until the result adds up.

What your company brings: deciding what gets cleaned up, what gets dropped and how much history you really need, and checking that the migrated data matches yours. The data is yours, and so is that decision.

6. Go-live, running alongside the old system

On switchover day you don't turn the old system off and the new one on. The safe approach is to run both for a while: one department or one location starts on the new system, results are compared with the old one and, once they match, you set the date for everyone else to move. The business keeps running, and errors show up while there is still a safety net.

7. Training

Training works best by role and with your own data: each person learns what they'll use, not a tour of every screen. The point person, who has watched the system grow demo by demo, becomes the one who answers day-to-day questions. That's why it should be someone who is going to stay.

8. Evolution

Software isn't finished on launch day. Use brings adjustments, and over time, new parts: the next phase left out of the first version, a report, another integration. The work continues the same way, in two-week cycles, with whatever level of effort makes sense at each point.

What you can't hand off to the vendor

A good vendor proposes, asks and warns you about consequences. But there are four things your company has to decide:

• Business rules: how each thing is done, and the exceptions.
• Priorities: what comes first and what can wait.
• Acceptance: whether what was delivered works for the job or not.
• Data: what is migrated, what is cleaned up and what is dropped.

When a custom project goes wrong, it's almost always one of these four that failed, not the technology.

What you get at the end

At the end of every phase, not just the last one, your company should have three things in its name: the code, in a repository under your account from day one; the documentation, so another team could pick it up if that day ever comes; and the data, in a format you can export. The cloud and domain accounts too. Why this matters so much is in who owns your software code.

How we do it at Vettra

This is the process we follow in our custom software development projects, and the most common type is a custom ERP or business management system that connects several areas. If you're weighing one up, tell us what you have today and we'll tell you how we'd approach the first few weeks.