I have spent my career on the business side of technology. I run programs, set direction, sit in the room where budgets get decided, and translate between people who build things and people who pay for them. What I have never done is write production code.

That has not stopped me from shipping three live apps, a website, and a set of automations that quietly run part of Two17-Tech while I sleep.

This is not a “learn to code in 30 days” story. It is the opposite. It is what happens when someone who knows what good delivery looks like finally gets a direct line to the build.

Quick detour before you read on. If you lead an active technology program that should be moving faster, the 8-question diagnostic takes about five minutes and lands in my inbox, not a sales queue.

The Receipts

Here is what is live today:

Yes or Mess: a reality TV prediction game with accounts, leaderboards, analytics, lifecycle email and threaded comments.
Cooper’s Journey: a pet health tracker for care, medications, records and milestones.
Digifolio: a portfolio management platform for tracking and presenting work.
keithprivette.com: the site you are on, built in Astro, with auto-scheduled posts and a diagnostic that writes straight to Google Sheets.
Automations for Two17: a weekly lead-generation engine that scans hiring signals and surfaces outreach targets, plus a pipeline that turns each blog post into short video and platform-ready captions.

None of these started as a code project. Every one started as a business problem with a person attached to it.

Spotlight: Yes or Mess

Yes or Mess began as a hobby. I watch a lot of reality dating shows, and every season turns into the same group-chat argument about which couples will make it. So I built a place to make the call, keep score and collect the receipts.

Then I ran it like a product, and that is where it got interesting.

What it does for players

Every couple has its own page with The Tea (did they last?), the split of what players predicted, and one tap to the rest of the cast.
The whole cast loads the day a season starts. Nobody has to set anything up.
Picks lock on their own at midnight Eastern on the lock date, so calls are final before the episodes drop.
Players get email when a new show lands, when picks open, when results are in, and when a new post goes up.
The blog has real threaded comments, with names shown as first name and last initial and private profiles kept anonymous.

What it taught me as a leader

Automate the operational toil first. Loading casts and locking picks by hand would have made me the bottleneck. The moment those became scheduled jobs, the product could grow without me in the loop. Every program I have run has a version of this problem.
Lifecycle communication is a feature, not a marketing task. The email alerts did more for engagement than any visual polish. Users want to know when something needs them.
Privacy is a design decision you make on day one. Deciding how names display and what a private profile means was a product call, not an engineering afterthought.
Ship small and often. Couple pages, auto-loaded casts, alerts and comments went out as separate releases, each tested against real players.

That is the same playbook I would bring to a claims platform, a member portal or a small business’s booking flow. The domain changes. The discipline does not.

The operating model behind all of it

People ask what tool I use. The honest answer is that the tool matters less than the operating model.

1. Frame the outcome. Before anything gets built I write down who uses it, what changes for them, and how I will know it worked. If I cannot say it in three sentences, I am not ready.

2. Pair with AI. I work with Claude as a build partner. It writes the code. I own the requirements, the trade-offs and the final call. Think of it as a very fast engineering team that needs a very clear product owner.

3. Test like the user. This is where a non-developer has an edge. I am not attached to the code, so I break things on purpose and reject anything that would embarrass me in front of a real customer. I can tell a bad implementation from a good one, even when I could not have written either.

4. Ship, then iterate. Real users, real data, small releases, repeat. Firebase, Astro, Google Sheets and a handful of APIs carry the load. None of them require me to be a developer. All of them require me to be a decision-maker.

Where is your program stuck between “framed” and “shipped”? The diagnostic is built to find exactly that.

Why this matters to executives

For as long as I have been doing this work, the gap between the business and the build has been where budgets go to die. Requirements get lost in translation. Decisions wait nine days for a committee. Post-mortems blame scope creep when the real cause was a decision nobody owned.

AI-assisted development does not remove that gap on its own. It shrinks the cost of building, which means the cost of unclear decisions is now the most expensive line item on the program. The organizations that win the next few years will be the ones whose leaders can:

describe the outcome precisely enough that it can be built,
judge what comes back without needing to read every line of it, and
make decisions at the speed the build can now move.

That is a leadership skill, not a coding skill. It is also the core of what Two17-Tech does.

Director-level details, for the people who will actually run it

If you are the one turning strategy into a delivery plan, here is what I would put in place first:

A one-page outcome brief per initiative. User, change, measure. Nothing gets built without it.
Decision rights mapped before kickoff. Who can say yes, who must be consulted, and what is pre-approved so routine calls never queue.
A test charter written by the business, not IT. Plain-language acceptance criteria that anyone on the team can run.
Release cadence measured in days. Smaller changes, faster feedback, less risk per release.
Automation for the recurring work. If a person does it on a schedule, it is a candidate for a scheduled job.
A shared, living record. A sheet or tracker that the diagnostic, the backlog and leadership all read from, so status reports stop being a separate project.

None of these require new headcount. Most of them require one honest conversation.

The 8 questions

I turned that honest conversation into a short diagnostic. Eight questions across four categories:

Outcome: Is the baseline documented?
Ownership: Is there an owner outside IT?
Alignment: Is the business case still aligned with what is being built?
Velocity: How long does a decision take to clear?

Most organizations can answer two or three cleanly. The gaps in the rest are usually where the budget, timeline and credibility problems are coming from.

Run the 8-question diagnostic →

Answer for one active program. It takes about five minutes. You get a direct read within one business day on what your answers suggest and whether a deeper conversation makes sense. No pitch meeting.

Ways to work together

Hampton Roads. If you run a business, nonprofit or team anywhere from Virginia Beach to Williamsburg, I am glad to meet in person, look at what you are trying to build, and help you get to a working first version.

Anywhere else. Most of my work happens over Google Meet. A 30-minute call is usually enough to tell whether an idea is ready to build, needs reframing, or should be stopped before it costs anything.

Conferences, networking events and podcasts. I speak on building without a programming language, AI-assisted delivery for business leaders, and why most technology failures are decision failures. If your audience is executives, operators or small-business owners who want to build rather than just talk about building, reach out on LinkedIn or through Two17-Tech.

Where to start

Pick one program you care about. Spend five minutes on the 8 questions. Whatever comes back, you will know where the drag is, and you will know whether the thing you have been waiting to build is closer than you think.

Business is technology and technology is business.

Keith Privette

Views are my own and do not represent my employers.