01
It started as a service, not software.
The first version had a different name and a simpler idea: a referral program for small service businesses, set up for them. Remodelers, roofers, cleaners, med spas, accountants. Businesses that already get most of their work from word of mouth and do nothing to encourage it.
The price was $99 a month, charged the day I set the client up. No free trial. Setup took one to two hours of my own work per client, and I was not going to give that away to someone who might never use it.
Technically, it copied what I had done with Crewli. Every client got their own database and their own copy of the app. For a service, that made sense. Each client was a small project I ran myself.
02
Four weeks in, I threw out the architecture.
On October 10, I changed the business model. Bonafide Crew would be self-serve: an owner signs up, sets it up and pays without ever talking to me.
That decision meant the one-database-per-client setup had to go. A business signing up at midnight cannot wait for me to build them a database. So I rebuilt the app on one shared database, with every business walled off from every other one.
I made that call before there were any customers, and the timing was the point. My note from that day: moving later, with real customers' data in it, is painful. Rebuilding an empty product costs a week. Migrating a live one costs trust.
The same choice I made for Crewli was the wrong choice here. The product was different, so the answer was too.
Crewli still uses one database per client, and that is still right for Crewli. I onboard every restaurant personally and the separation is a safety feature. Bonafide Crew has no onboarding call, so the same separation would have been a wall between a customer and their first five minutes.
03
It is not a referral tool.
The rebuild also changed what the product was. A referral program on its own is a feature. What an owner actually wants is for the next sale to be easier, and referrals are only one way that happens.
So Bonafide Crew became three tools around that one job, shown above: one for the partners who send you work, one for the clients who already love you, and one for showing a prospect jobs like theirs.
One rule held across all three: partners and clients never make an account. Every login you ask a stranger to create is a place where they stop.
04
No sales calls, ever. So the product has to sell itself.
I decided early there would be no sales calls and no demos. At this price, a call for every customer does not pay for itself, and it would have turned software back into the service I had just walked away from.
That moved the whole weight of selling onto the first day inside the app. The Today screen opens with six setup steps that fill the account with the owner's own material: their logo, their best jobs, the testimonials they already have, their first partners. All of them can be skipped except adding partners, because without partners there is no product.
I also cut something I liked. A question at signup asked what kind of business you run, so the wording could fit a roofer differently from a med spa. It made the product feel tailored. It also made every screen twice as hard to build and test. I decided it was too complicated and took it out.
After setup, Today only shows things that actually happened. A partner sent someone. A job got finished. A client is happy and has not been asked for a testimonial yet. An earlier version showed rotating ideas when nothing was going on. I removed them. A to do list that invents work is one people learn to ignore.
05
Why $79, and not less.
Bonafide Crew costs $79 a month for up to ten people and $149 for up to twenty-five.
I looked at $49 and $60. Cheaper would have been easier to sell, and it would have put Bonafide Crew next to the referral-only tools at the bottom of the market. The argument for $79 was simple: one extra client a year pays for it many times over. And lowering a price later is easy. Raising it is hard.
The plans charge by team size, with no fee per person. Charging per seat would have given owners a reason to keep their staff off the app, and the more people use it, the less likely the business is to cancel.
A discount I built and then deleted
I designed founder pricing: $49 locked in for the first ten customers, with one-time random codes. I took the word "founder" out of the codes because it would have been guessable.
Then I decided never to advertise it, because a product that looks established sells better than one asking for early believers. On November 2 I removed it entirely. Everyone pays the same price.
06
Designing the trial.
The done-for-you version had no trial. Self-serve needed one, because without a call the trial is the only sales pitch.
It started at seven days. I moved it to fourteen the next day. A service business owner might not get a referral in a single week, and a trial that ends before anything happens proves nothing.
A card is required, and the plan starts charging on its own when the trial ends. Then, on October 25, I changed when the trial starts: from the moment of signup to the moment the card goes in.
The reminder before the first charge comes from Stripe, seven days before the trial ends, not from an email of my own. That was deliberate. It means no surprise charges, no promise I could break with a bug, and a record held by the payment company that the reminder went out.
Without a sales call, the trial is the sales call.
07
Billing is where trust breaks.
A bug in a referral page is an annoyance. A bug in billing charges somebody twice. So I spent more time on what happens around a payment than on any single feature.
- A payment fails. The owner sees a red card on Today. Stripe retries eight times over two weeks. Their pages stay open for up to twenty-one days before anything shuts off.
- Someone cancels. They keep what they paid for until the end of the month. Stripe sends no email when a plan is canceled, so I wrote one.
- Someone clicks pay twice. Open checkout pages expire, and a second plan is refused, so nobody is charged twice.
- Someone switches plans during the trial. Stripe has a setting that ends the trial on any change to the plan. I left it off, because it would charge a trial customer the moment they upgraded.
- A plan ends. Nothing is deleted right away. Everything comes back if they return within ninety days. They get warnings on day sixty and day eighty-five, and their data is erased on day ninety.
Every message from Stripe is checked for a valid signature, and the app re-reads the subscription from Stripe instead of trusting what the message says. The key the app uses can do six things, and none of them move money.
I tested it all in Stripe's test mode, then on the live system with my own card: nothing charged today, trial started, plan canceled.
08
What I built, then removed.
Some of the most useful work on this product was taking things out.
- A "talked" status on referrals. Useful on its own, but it was the first step toward a sales pipeline, and Bonafide Crew is not a CRM. Owners already have somewhere they track deals.
- A team scoreboard. I built it on October 12 and removed it on November 1.
- A manager role. Built on October 30. A day later I decided one owner runs everything. The code is still there if a real customer ever needs it.
- A button asking clients for a review on Google. Removed. Review rules are strict, and I did not want a feature that could get a customer in trouble.
- Quote tracking and follow-up. Planned, never built.
When I wrote the feature list for the website, the first draft had twenty-four items. I cut it to the features that actually exist and do something on their own. I would rather a customer find more than they expected than less.
09
Security, as someone who is not an engineer.
I build with AI. That means I can ship a real product, and it also means I have to be honest about what I might not know. With one shared database, the worst thing that could happen is one business seeing another one's partners or clients.
So every table has rules in the database itself that decide who can see each row. Hiding something in the interface does not count. I test it by creating two businesses and trying to reach one from the other.
On October 12 I ran a break-it test: twenty fake businesses, hundreds of partners and referrals, and fifty-nine deliberate attacks. All fifty-nine held, once I added limits on how long each field can be. Three more rounds of testing on October 29 found real problems, including a way to save a script into a page, which I fixed. By October 31, seventy-five attacks held.
The public pages, the ones partners and clients see, live on their own separate domain. If someone ever abuses a page to post something harmful, the main domain and its email stay clean.
What this is and is not
This is careful testing by the person who built it. It is not an outside security audit, and I don't present it as one.
10
Where it stands today
The first commit was on September 13. The website went live on October 12. The app opened for signups on October 31. That is seven weeks, and 347 commits, from idea to a product a stranger can sign up for and pay.
Since then the work has moved to getting found. There are thirty-seven articles on the blog, built from keyword research. Bonafide Crew is listed on G2, Capterra, GetApp and Software Advice. There is a short video on the homepage showing how it works. No ads have run yet.
What I cannot tell you yet
Signups have been open for about a week. There is no conversion rate here, no retention and no usage data, because a week is not long enough for any of those to mean anything.
What I can say is what I'll want to know first:
- How many people who start a trial put a card in, and how many of those are still paying after the first charge?
- Do owners actually send partners their links, or do they set up the partners and stop?
- Do clients fill in the testimonial link when it arrives, or does it sit unopened?
The first one tells me whether the product sells itself. The other two tell me whether it does its job once it has.
11
What I got wrong
Every test passed. The forms didn't work.
Early on, the public forms had a test switch left on. Every check I ran against the system passed, and not one form a real person filled in ever went anywhere. In the same week I found that the app was showing whichever person came first in the database, not the person who was logged in.
Both were invisible from the inside. The lesson I wrote down that day: test through the real screens, the way a customer would, not only through the parts underneath.
I built for customers I didn't have yet.
The scoreboard and the manager role were both reasonable ideas. Both were built before a single customer asked for them, and both came out within weeks. Building is fast for me now, which makes it easy to build the wrong thing quickly. The cost was not the time. It was a more complicated product for every new owner to understand.
The most important email went to Promotions.
The email telling an owner they had a new referral is the one that matters most. With "New referral" in the subject line, it landed in the Promotions tab, where it would be missed. Rewording it got it into the main inbox. Something that small could have quietly made the whole product look like it wasn't working.
12
The question still open.
The whole business rests on one early decision: no sales calls and no demos. The product, the trial and the first day inside the app are all designed so that an owner never needs to talk to me.
The first goal is fourteen paying customers. What I don't know yet is whether a product can find its first fourteen through search, listings and the product itself, or whether the first few have to come from a conversation.
- If trials start but cards don't go in, the first day isn't selling well enough.
- If nobody starts a trial, the problem is in front of the product, not inside it.
- If the first customers only come from conversations, that tells me something about the rule itself.
I'll know which within the next few months. Deciding now what each answer would mean is how I keep myself from explaining it away later.