Carolina Custom Surfaces · Sales CRM · Version 1
It isn't. This page is a record of what actually went into making a working CRM for our sales team — measured, not estimated, and counted straight out of the project's own files.
The shape of it
working days out of every one available carried committed work.
01Why not just buy one
For the life of this company, new work has come from two places: referrals, and prospecting. Referrals are not a strategy. They are what happens when you take care of people well enough that they mention you — real, valuable, and almost entirely outside anyone's control on a given Tuesday. Prospecting is the other one, and it is the only proactive lever the company has.
So the thing worth measuring was never "leads." It was effort: who is being contacted, how often, by what method, and what came of it. That is a coaching problem before it is a software problem, and you cannot coach what nobody wrote down.
Two large parts of a normal CRM turned out to be dead weight.
The first is marketing attribution — the machinery connecting spend to opportunities. Most of the market is built around it. We don't spend meaningfully on lead generation and have no plan to start; what we do spend goes to brand awareness, which doesn't attribute. The insight that machinery produces is bounded by the spend behind it, so for us it would have meant a great deal of logging and very little to learn.
The second is account care. Our salespeople spend most of their day looking after customers who already bought, and they do it well — that work is the reason the referrals exist at all. Requiring them to log it would have taxed the thing that already works, to produce a record nobody was going to act on.
Strip both away and what remains is prospecting activity. Most CRMs track it adequately. All of them surround it with several other products.
Then there is who uses it.
This is a seasoned sales team and a non-technical one. Friction isn't an inconvenience here, it's the entire risk — two earlier attempts didn't fail on features, they failed on adoption. Every extra field is one more chance for the record to simply not get made. So the system had to ask for as little as possible while still producing something worth evaluating, and it had to make what the company now values visible from the screen, without a meeting about it.
The stages, the cadences, the outcomes, the way activity rolls up against a goal — none of it is generic. It is this company's pipeline, this company's sales motion, named the way the people here already name it. A version of it would probably work elsewhere. It wasn't built to.
02Before a single feature existed
Software gets specified before it gets built. Every screen, rule and edge case is described in writing first, argued over, then handed to the machine that types it. That written layer is invisible in the finished product and it is where the time goes.
03The thing itself
All of it sits behind our Microsoft sign-in, connects to Outlook mail and calendar, and takes leads straight off the website.
Inside the database, read live:
04Who can see what
A salesperson sees the team's records. A manager sees more. The owner sees everything. That is easy to state and easy to get wrong, so it is enforced in the one place a mistake in a screen cannot reach.
Sign-in is inherited from the company's Microsoft account, with the same multi-factor requirement as company email. There is no separate password to leak, reuse, or forget — and when a mailbox is closed, access ends with it.
Who may read or change a row is decided by the database, underneath the application. Application code is a second line of defence rather than the first, so the rules hold even where a page is wrong.
Edits are logged where they happen, which means the log cannot be skipped by a code path that forgot to write to it. Salespeople cannot read that log; the owner can.
A deletion is a request until a manager approves it, and an approved record is hidden rather than destroyed, recoverable for a fixed window before it goes for good.
05The part nobody sees
Working software is not software that worked once. Each of these is a small automatic test that re-runs on every single change, so a fix in one place cannot quietly break something in another.
06Rework
Nothing was specified once and left alone. Plans met reality, reality won, and the change had to be written down before the code could move — which is why so much of the effort above is words.
None of that churn ever reached the team.
It was specified, built, tested, and never shipped — stopped by a change of direction the day after the last of it was written. The work is parked intact rather than thrown away, so it can be picked up if the decision changes.
07What outlasts the person who built it
This is the answer to a question nobody has asked yet. The approved plan flagged one risk as unlikely but severe: the person building this becoming unavailable. The mitigation written there was documentation good enough that somebody else could pick it up.
Kept in a company repository, on company accounts, under CCS ownership — same as the CRM itself.
08What it cost, and what buying it would
The honest trade.
09After the launch
A system that still demands its builder every day a year in is a system that isn't finished. This one gets picked up when a need comes up — a fix, a feature the team asked for, a rule that turned out to work better another way — and left alone the rest of the time. The figures below are totals since the team went live, and they only ever go up.