One person, from brief to build: how I run a Salesforce project start to finish

A fictional small business, in a real, fully working Salesforce environment. My role: discovery, build planning, configuration, testing and the walkthrough.

The problem

Moving to Salesforce takes two kinds of work. Someone has to work out what you need. Someone has to build it.

A small business does not need a team for that. It needs one person who can do both, and explain it in plain language along the way.

This build shows both, done by one person. I took a small service business from a written brief and a recorded briefing to a fully working Salesforce setup: the plan, the build, the testing, and a recorded walkthrough for the owner and for the person who would maintain it. It is the way I would work with you.

How I worked

I planned before I built.

I had the recorded briefing transcribed and read it next to the brief. Then I worked with Claude, an AI assistant, to turn both into a plan: what to build, in what order, how much time each part should take, and the questions I still needed answered. Nothing went into Salesforce until the plan made sense. For you, this is the part where we talk about what is actually getting in the way, before anyone spends money building around the wrong problem.

I made decisions out loud.

Everything lived in Notion, a shared workspace: a build log, a list of open issues, a list of tests and a time log. Every issue got the same treatment. I wrote down the problem, the options and my recommendation, then the decision and the date. On your project you would see the same thing. When a choice comes up, you get the options and my recommendation, and you make the call. Months later, anyone can look back and see why things are the way they are.

I built for how people actually work.

An owner knows what they want out of a system, and sometimes asks for it in terms of how the system should behave. "Make every field required so nobody can skip anything" is a good example. The goal behind it is right: complete, trustworthy data. But a screen that demands everything at once teaches busy people to stop logging, or to type anything just to get past it, and the data gets worse.

So I start from the goal, not the instruction. In this build I required only the handful of fields the owner's reports depend on, and only at the step in the process where that information actually exists. Logging stays quick, and nothing important gets skipped. When I explain that, I show the owner the report the rule protects, so they can see they got what they were really after.

I built only what was needed.

I used standard Salesforce features wherever they fit, because standard features are easier to maintain and cheaper to change later. I kept a written list of what I chose not to build, and why. I also wrote down the questions I would ask before going live. Every extra thing that gets built is something you have to maintain, so knowing when to stop is part of the job.

I used AI openly, and stayed in control.

Claude helped me plan. It drafted my build summary, my walkthrough script and an appendix, and I reviewed and edited each one. In my browser, with my approval before every step, Claude also created the demo records, built the reports and dashboard from specs I approved, did small setup tasks and ran my tests. I did the core configuration myself, and I can explain and defend every decision in the build. AI made me faster. It did not make the decisions.

I tried to break my own work.

Before I recorded anything, I tested the build the way a busy, real user would. I skipped fields. I did steps out of order. I saved the same record twice. I tried to delete something other records depended on. When something failed, I fixed it and tested again. Then I reset the demo data so it matched my script. You should not be the first person to find a problem.

I explained it twice.

I wrote one script: what I click, what I say and the points I had to land. I used tell, show, tell. Slides framed the start, the middle and the end, and the demo itself ran without interruption. The first half was for the owner, in business language only: what it does for you and how your people will use it day to day. The second half was for the person who would maintain it: how it works behind the scenes and how to keep it running after I hand it over.

What the owner got

A working Salesforce setup, tested before anyone else touched it.
The plan, and a written record of every decision and why it was made.
A list of what I chose not to build, and the questions to settle before going live.
A walkthrough for the owner, and a separate one for whoever maintains it.
A written summary of the build, including exactly where AI was used.

When something went wrong

Things go wrong on projects. What matters is how they get handled.

My first full recording came back with unusable audio. I re-recorded, and on the second take the microphone was off. Neither one was something I could hand over.

I did not send a "good enough" version or hope nobody would notice. I caught both problems on review, before anyone else saw them. I found the cause, fixed my setup and recorded again. Then I adjusted my own schedule to absorb the lost time, and the delivery date never moved. I still delivered ahead of the deadline.

Afterward, I wrote down what happened and what I use now, so the same mistake does not cost time twice.

That is how I handle surprises on a client project too. You hear about it from me, early, along with the fix. And when the problem is on my side, I absorb it. Your deadline does not move because of my mistake.

What you can expect working with me

We start with what is getting in the way, not a feature list.
Before anything is built, you see a plan and the questions I still need answered.
When a choice comes up, you get the options and my recommendation. You decide.
If something you ask for would work against what you are trying to achieve, I tell you why, and show you a way that gets you there.
I build only what you need, and tell you what I left out and why.
I test it before you see it.
You get a walkthrough in plain language, and whoever runs it after me gets their own.
You see where I used AI, and what I did myself.
If something goes wrong, you hear it from me, with the fix. If the problem is on my side, I absorb it, and your deadline holds.

One person who works out what you need, then builds it, and explains it in plain language.

Portfolio build: a fictional small business, in a real, fully working Salesforce environment. Business details are left out on purpose.

Moving to Salesforce, or stuck partway through? Pick a time. Bring the problem, even if you cannot name it yet.

Get in touch Pick a time