Most consultants run their practice on a stack of seven SaaS tools that were built for somebody else's business. I built mine on Django because I wanted the platform to know me, not the other way around.

This is the story of NAWeb — the platform you're reading this post on right now — and the trade-offs I made building it instead of buying it. It's also the story of why I would not recommend you do the same thing unless your situation looks a lot like mine.

## The setup

When I left CVS to start Nellson Associates, I had a choice. I could spend the first three months of my independent practice setting up a stack — Stripe for payments, Calendly for booking, HubSpot or Notion for CRM, ConvertKit for email, Memberful or Patreon for community, Squarespace or Webflow for the public site, DocuSign for contracts, and a half dozen Zaps to stitch them together. Maybe $300/month in subscriptions and a week of integration work every time something broke.

Or I could spend those three months building a single Django application that did all of it. One database, one auth system, one deploy pipeline, one place to look when something went wrong.

I chose to build. Here's what that decision actually bought me — and what it cost.

## The three revenue paths NAWeb handles

NAWeb has three distinct revenue paths and they all flow through the same codebase:

**Consulting engagements.** A client comes through the contact form, we run them through an AI-powered intake to surface scope and constraints, generate an engagement brief, route them to the right consultant, and then run the engagement through invoicing, contracts, and payment. All in one app, one database, one set of permissions.

**Community subscriptions.** Three tiers — Observer, Participant, Insider — with monthly recurring billing through Authorize.Net's ARB system. Tier-gated content (including this post you're reading), Discord role assignment when you link your account, and a manage-subscription dashboard where you can cancel without emailing support.

**Book sales.** One-time purchases of "So, You Want To Be A Consultant" — the practical guide my father wrote and updated. Same payment infrastructure, same security checks, different product flow.

The thing that matters: all three of these share the same user accounts, the same permission system, the same security infrastructure, the same audit log. When you buy a book and then later subscribe to the community, you don't have to create a second account or link two services. The platform already knows you.

## Magic-code authentication

I refuse to manage passwords for a small audience.

Nellson Associates serves a few hundred clients and community members at any given time. The risk-reward of running a password reset flow, dealing with forgotten credentials, and inevitably having one of those passwords show up in a credential dump somewhere — none of that is worth it for a practice this size.

So NAWeb uses magic-code authentication. You enter your email, we send you a one-time six-digit code, you enter it, you're in. No password to forget, no password to leak, no password to crack. The code expires in ten minutes and uses timing-safe comparison so brute-forcing it is impossible.

Is this the right call for everyone? No. If I were running a marketplace with ten thousand daily logins, the friction of a magic code would tank engagement and the value of a stored credential would be much higher. But for a consulting practice where someone might log in twice a month, magic codes are perfect. Lower friction than a password (you don't have to remember anything), better security (no credential to steal), and zero support burden for me.

The lesson generalizes: pick the auth model that matches your actual usage patterns, not the one that the SaaS marketing pages tell you everyone uses.

## The DummyGateway toggle

My favorite piece of NAWeb is a toggle in the admin that switches the entire payment system between live Authorize.Net and a fake gateway that always succeeds (or fails, or declines, depending on which test scenario you pick).

The reason this matters: I can demo every payment flow on a real production deploy without ever touching real money. When I show a prospective client the engagement intake → contract → payment flow, I flip the toggle, walk through it, and flip it back. When I'm testing a new feature, same thing. When I'm troubleshooting a bug a user reported, I can reproduce it against the same code path that runs in production.

The DummyGateway also lets me run the full integration test suite without hitting Authorize.Net's sandbox API, which means tests run in seconds instead of minutes.

If you're building anything that handles money, build a DummyGateway equivalent before you write the real integration. You will save yourself an enormous amount of pain.

## The Scholarship Fund — building the moral architecture into the code

Half of every book sale and half of every community subscription payment goes to the Nellson Associates Scholarship Fund. Not as a marketing gesture — as a structural feature of the platform. Every successful payment automatically writes a `ScholarshipContribution` row that gets aggregated on a public dashboard at /scholarship-fund/.

I'll write more about why I structured the practice this way in another post. The point for now is that the moral commitment lives in the code, not in a blog post or an "About Us" page. If you want to know how much the fund has raised, you can read the SQL. If you want to see where it's going, the dashboard shows aggregate disbursements. The transparency is enforced by the platform, not by my willingness to remember to update a spreadsheet.

This is the kind of decision you can only make when you control the platform. You cannot bolt this on top of a SaaS stack. You'd be writing custom code anyway, so you might as well write it inside an app you already control.

## What it cost me

Building NAWeb cost me about three months of full-time engineering work upfront, and it costs me about two days a month in ongoing maintenance — bug fixes, deploys, infrastructure tweaks, occasional new features when a client request reveals a gap.

In billable-hour terms, the upfront cost was something like $60-80k of foregone consulting revenue. That is not nothing.

What I got for it: a platform that does exactly what I need it to do, with no dependency on a vendor that might raise prices or change their API or get acquired and pivot. A codebase I fully understand, can extend in an afternoon, and can demo without paying for sandbox accounts. A unified database where one query can answer "how is the practice actually doing?" without exporting from six different sources.

For me, with my background, on this timeline, that math worked. For most consultants it would not. If you don't have a decade of production engineering experience, building your own practice platform is going to take longer than you think and the maintenance will eat the time you wanted to spend on client work. Buy the SaaS stack. It's fine.

## When I would build again

The honest test: would I do it the same way if I were starting over today?

Yes — but only because the practice I wanted to build had three specific properties that made the SaaS approach especially expensive.

One, I needed all three revenue paths to share user accounts and permissions, and stitching that together across separate SaaS tools is a permanent integration tax.

Two, I wanted the scholarship-fund mechanic baked into every transaction at the data layer, which is the kind of thing you can't easily express in a no-code workflow tool.

Three, I'm the engineer. The opportunity cost was real but not catastrophic, and the platform I built is a moat — competitors who run on stock SaaS can't replicate my operating model without doing what I did.

If even one of those three was missing, I'd buy. Probably.

## The lesson

Build the platform that matches the practice you want to run. If your practice is identical to everyone else's, buy the stack and spend the time you saved on the work. If your practice is structurally different in ways that matter to you, and you have the engineering capacity to maintain a custom system, building can buy you something you cannot purchase any other way: alignment between the tool and the work.

The platform should know you. Not the other way around.