How a custom CRM actually gets built

A business decides to build rather than buy, and the conversation moves immediately to features and to a quote. What gets agreed is a list of screens and a number.

That is the point at which most custom software projects are already in trouble, and it is not because the estimate was wrong. It is because the list of screens is not the thing being built. The thing being built is a change to how a business operates, and the software is the smaller half of it.

Projects that go badly rarely go badly because of engineering. They go badly for three reasons, all of which are visible before any code exists.

The three ways these projects fail

All three columns point at the same phase, which is why the next section is longer than the ones about building.

Discovery is where the money is saved

Discovery is regularly treated as a delay before real work starts, and is therefore compressed. It is the phase with the highest return, because everything found here is cheap and everything found later is not.

1. 1

   Map the process as it actually runs

   Not as documented, and not as management describes it. The two differ, and the difference is usually where the real requirements live — the workarounds people invented are the specification.

2. 2

   Look at the real data

   Not the schema, the contents. Count duplicates, count empty required fields, find the free-text field being used to record three different things. This is the single most predictive activity in the whole project.

3. 3

   Identify every system this must exchange data with

   And check each one's actual API, not its marketing page. Integration is where estimates break, and an assumed API that turns out to be a nightly CSV changes the design.

4. 4

   Write down what version one does not do

   The exclusion list is more useful than the feature list. It is what makes scope discussions short later, because the answer is already written and agreed.

5. 5

   Name the people who must adopt it

   Individually. Then involve them now, while their input can still change the design cheaply.

6. 6

   Agree what success looks like, measurably

   Not 'better visibility'. A number that will be different, and how it will be observed. Otherwise there is no basis on which the project can be declared finished.

The data step deserves the emphasis it is given. Almost every custom project that overruns does so partly because the existing data was worse than anyone believed, and the discovery that it is worse arrives during migration — the point at which the schedule has no slack and the design assumptions are already built.

The phases, and what each is for

Two of these rows are consistently underestimated.

Migration is a phase, not a task

Moving data between systems is not a copy. Fields do not correspond, one system's required field is another's optional, historical records follow rules that no longer apply, and duplicates have to be resolved by decisions somebody must make.

It also needs verification that goes beyond a row count. Counts matching proves nothing about whether the right values landed in the right fields, and the errors that matter are the ones that look plausible.

Adoption is most of the risk after launch

A system nobody uses has the same business value as a system nobody built, at considerably higher cost. People continue using the spreadsheet for rational reasons — it is faster for the thing they do most, it does not require them to fill in a field they consider pointless, or nobody asked them what would make the new system usable.

• Involve the actual users during discovery, not at training. By training it is too late to act on what they say, and they know that.
• Make the new way faster than the old way for the task done most often. If it is slower, no amount of instruction will hold.
• Retire the old way deliberately, on a date, rather than leaving both running. Parallel running indefinitely guarantees divergence and halves the value of both.
• Watch actual usage after launch. Records created, per person, per week. It tells you the truth that a satisfaction survey will not.

Building in a way that reduces risk

Beyond process, a small number of engineering decisions materially change how the project goes.

• Ship something usable early, even if narrow. Feedback on working software is worth more than feedback on a document, and it arrives while changing direction is still cheap.
• Get the data model right before the screens. Screens are inexpensive to change; a data model with a wrong assumption baked in is not, and everything else depends on it.
• Build the integrations early rather than last. They are the highest-risk component and the one most likely to invalidate an assumption, so their surprises should arrive while there is time.
• Automate deployment from the beginning. Manual deployment produces environments that differ from each other, which produces defects that only appear in production.
• Instrument it. A system nobody can observe is a system whose problems are reported by users, which is the slowest and most expensive detection mechanism available.

That last point extends past launch. Custom software has no vendor watching it. If nothing monitors whether the nightly sync ran, the answer arrives as a complaint about missing data some days later.

Ownership after launch

Custom software is not finished at launch; it is transferred into operation. The question of who maintains it is answered at the start or it is answered by default, and the default answer is nobody.

• Who fixes defects, and within what response time.
• Who decides what changes get made, and how they are funded.
• Who patches the underlying platform when a framework or runtime reaches end of life — this is the obligation most often unassigned.
• Where the source code, the deployment process and the credentials live, in a form that survives the departure of whoever built it.

The third item is the one that quietly ends custom systems. A system built on a framework version that stops receiving security updates becomes a liability on a known date, and if nobody owns that, the business finds out when something else forces the issue.