DEV Community: Matt Senter

Building a Nonprofit Is a Different Kind of Challenge

Matt Senter — Fri, 17 Jul 2026 15:18:37 +0000

A few weeks ago, BeeReady officially received its 501(c)(3) determination from the IRS.

On paper, that means we're now a federally recognized nonprofit organization. It's an important milestone that opens the door to grants, tax-deductible donations, and a stronger foundation for the work ahead.

For me, though, it represents something more personal.

I've spent most of my career building technology companies. Startups. Products. Engineering teams. Consulting businesses. Revenue models. Those are familiar problems.

A nonprofit requires an entirely different way of thinking.

Before BeeReady, my experience with nonprofits was mostly from the perspective of serving on a board. I understood governance at a high level, but I'd never helped create an organization from the ground up. I assumed many of the lessons from startups would carry over.

Some have.

Many haven't.

The Mission Is the Business

One of the first things that surprised me is that a nonprofit still has to solve nearly every operational problem a startup does.

You still need strategy.

You still need marketing.

You still need accounting.

You still need technology.

You still need operations.

You still need security, policies, documentation, websites, fundraising, volunteer management, project management, and countless hours of coordination.

The difference is that every decision starts with the mission.

Revenue isn't the goal. It's simply one of the tools that allows the mission to continue.

That subtle shift changes almost every conversation.

Governance Matters More Than I Appreciated

Coming from startups, my instinct has always been to move quickly.

Build something.

Test it.

Improve it.

Repeat.

Building BeeReady has taught me that some things deserve to be intentionally slower.

Board governance.

Conflict-of-interest policies.

Financial controls.

Volunteer protections.

Youth safety procedures.

Record retention.

These aren't the glamorous parts of building an organization, but they're the foundation that earns trust from volunteers, donors, parents, and the communities you hope to serve.

I've spent far more time reading IRS guidance, nonprofit regulations, and governance best practices than I ever expected.

That's not something I imagined I'd be doing this year.

Building Is Still Building

The encouraging part is that many of the skills I've developed over the years still apply.

Systems thinking applies.

Automation applies.

AI absolutely applies.

Process design applies.

Documentation applies.

Good software makes organizations better, regardless of whether they're generating profits or serving a public mission.

I've probably written as many internal operating documents for BeeReady as I have for startups.

The difference is that instead of improving customer acquisition funnels, we're figuring out how to make volunteer onboarding smoother, simplify AED management, and make it easier for communities to become prepared for cardiac emergencies.

It's still systems engineering.

The outcome is simply measured differently.

Always Be Willing to Become a Beginner Again

One of the best parts of this experience has been realizing how much I still have to learn.

After years of building companies, it's easy to assume you've developed a playbook that works everywhere.

You haven't.

Every new challenge exposes assumptions you didn't know you were making.

That's uncomfortable, but it's also one of the fastest ways to grow.

BeeReady has given me the opportunity to become a student again, and I've enjoyed that more than I expected.

Onward

Receiving our 501(c)(3) status isn't the finish line.

It's the starting line.

There's still fundraising to do, volunteers to recruit, partnerships to build, and technology to create.

Thankfully, I get to tackle those challenges alongside my wife, Dr. Andi Senter, our co-founder Dr. Elda Fisher, an incredible board, and a growing group of volunteers who all believe in the same mission.

I'm looking forward to sharing what I learn as we continue building BeeReady.

If nothing else, it's proving that even after decades of building businesses, there's always an entirely new discipline waiting to humble you.

I Left My Day Job to Teach My Kids How to Build Businesses With AI

Matt Senter — Sun, 05 Jul 2026 23:26:03 +0000

I recently left my role at Superlogic.

I am not leaving technology. I am not stepping away from
building. And I am not taking a traditional sabbatical.

Instead, I am using this next chapter to focus on my family,
help build a nonprofit, and teach my kids how to create
real products and businesses with AI.

That last part is the experiment I am most interested in.

My kids are growing up in a world where the cost of turning
an idea into working software is dropping fast. A motivated
person can now move from concept to prototype in days,
sometimes hours.

But faster development does not automatically produce better
products.

AI can generate code, designs, copy, research, and business
plans. It cannot reliably decide which problems are worth
solving, whether users actually care, what tradeoffs are
acceptable, or when a product is ready to ship.

Those are the skills I want to teach.

## The goal is not to teach them prompting

I am not trying to train my kids to become professional
prompt engineers.

I want them to learn how to build.

That means learning how to:

notice real problems
talk to potential users
test assumptions
define a small first version
use AI to accelerate execution
inspect and challenge generated work
launch something publicly
measure what happens
improve it or shut it down

The AI tools are important, but they are not the curriculum.

The curriculum is judgment.

A child who can ask an AI model to generate an app has done
something interesting. A child who can explain why the app
should exist, who it serves, how it might make money, where
it could fail, and what should be built first has learned
something much more valuable.

## Senternet is our workshop

I have launched Senternet, a
product and consulting studio. The name is not new:
Senternet was my first company, founded 27 years ago, and
reviving it now feels right.

It is the umbrella under which I will build products, create
apps, advise companies, and experiment with new business
ideas. My kids will participate where it makes sense, not as
passive observers, but as contributors.

That may involve:

researching a market
naming a product
interviewing users
designing an interface
creating marketing assets
testing a prototype
reviewing analytics
helping decide what to build next

Some projects will be client work. Others will be products
we own.

Some may become businesses. Some will fail quickly. That is
expected.

I want them to experience the entire loop from idea to
execution, including the uncomfortable parts: unclear
requirements, bad assumptions, bugs, rejection, and users
who behave differently than expected.

AI makes it easier to build the wrong thing faster.

The only defense is learning how to think.

## We will use AI, but we will not outsource responsibility

My background spans engineering, security, operations,
product, design, and executive leadership. I have worked as
a CEO, CTO, COO, CISO, founder, and builder.

The most useful thing I can teach my kids is not a specific
framework or programming language. Those will change.

I can teach them how to reason through systems.

When we use AI to generate software, they will need to ask:

Does this code actually work?
Is it secure?
What assumptions did the model make?
What data are we collecting?
Who owns that data?
What happens when the API fails?
How much will this cost at scale?
Are we solving the original problem or just adding features?
Would someone pay for this?
Should this exist at all?

The model can produce an answer.

The builder still owns the consequences.

That distinction matters, especially for kids who may
otherwise grow up believing that plausible output is the
same thing as correct output.

## Bee Ready gives us a real-world problem to solve

I will also be volunteering with Bee
Ready, a nonprofit co-founded by
my wife, Andi Senter, another physician mom, Elda Fisher,
and me.

Bee Ready is focused on improving emergency preparedness at
youth sporting events through CPR and AED training, visible
volunteer response teams, and better access to lifesaving
equipment.

I will serve as CTO and COO.

That means helping with technology, operations, internal
systems, volunteer coordination, data collection, and the
infrastructure required to grow the organization.

This gives us something better than a classroom exercise.

It gives us real constraints.

Nonprofits have limited budgets. Volunteers have limited
time. Users may be stressed, distracted, or nontechnical.
Systems need to work at fields, pools, and community events.
Software cannot exist just because it is interesting to
build.

It has to reduce friction.

It has to support the mission.

And in this case, failure can matter.

That makes Bee Ready an unusually meaningful environment for
teaching product development, operations, and responsible
technology.

## The stack matters less than the process

We will use modern AI-assisted development tools. That will
likely include coding agents, design tools, automation
platforms, cloud services, analytics, and traditional
development environments.

But I do not want this project to become a running list of
tools.

Tools change too quickly.

The repeatable process is more important:

Find a real problem.
Define the user.
Identify the riskiest assumption.
Build the smallest test.
Use AI to accelerate the work.
Review everything critically.
Put it in front of real people.
Measure behavior instead of collecting compliments.
Decide whether to continue.

That process works whether the product is a mobile app, a
nonprofit workflow, a consulting service, or a small online
business.

It also prevents AI-assisted development from turning into
endless prototype generation.

Shipping is not the end of the process.

Shipping is when reality starts grading the work.

## I expect them to fail

I do not expect every project to succeed.

I would be concerned if they did.

A project nobody uses can teach positioning.

A product nobody buys can teach pricing.

A confusing onboarding flow can teach design.

A security mistake can teach threat modeling.

A feature that takes three weeks and adds no value can teach
scope control.

The point is not to manufacture a string of impressive
launches for social media.

The point is to help them develop the ability to recover,
adapt, and keep building without confusing failure with
personal inadequacy.

AI reduces the cost of experimentation. That should make us
more willing to test ideas, not more attached to every idea
we generate.

## This is also an experiment in education

Traditional education often separates disciplines.

Programming is one subject. Business is another. Writing,
design, finance, operations, and marketing live somewhere
else.

Building a product combines all of them.

A small software project can require a student to write
clearly, think mathematically, understand users, evaluate
tradeoffs, manage time, communicate decisions, and accept
criticism.

AI can help at every stage, but it also creates a new
educational problem: students can produce work they do not
understand.

So one rule will be simple:

You should be able to explain what you built.

That does not mean memorizing every line of generated code.
Professional developers already rely on frameworks,
libraries, abstractions, and tools they did not write.

It means understanding the system well enough to reason
about its behavior, limitations, risks, and purpose.

If you cannot explain why it works, you are not done.

## What I plan to write about

I intend to document this experiment.

That may include:

how we choose projects
how I teach kids to use coding agents responsibly
where AI-assisted development works well
where it creates hidden problems
how we validate product ideas
how we structure small family projects
lessons from building nonprofit technology
mistakes we make
products we launch
projects we decide to kill

I am especially interested in the gap between generating
software and building a business.

That gap is still enormous.

AI is making implementation cheaper. It is not making
customer understanding, distribution, judgment, leadership,
or accountability obsolete.

In many cases, it is making them more important.

## A different kind of career move

Leaving a day job is often framed as a dramatic leap into
entrepreneurship.

This feels different.

I am not betting everything on one startup. I am building a
studio, helping operate a nonprofit, spending more time with
my kids, and creating a place where we can test ideas
together.

For most of my career, I have helped companies build
products and solve technical problems.

Now I want to apply that experience more directly, while
teaching the next generation of my family how to create
rather than simply consume.

We will use AI heavily.

We will also question it, test it, reject its output, and
take responsibility for what we ship.

That is the part of AI-assisted building I think matters
most.

I Built Reusable Claude Code Skills to Ship Production Websites Faster

Matt Senter — Thu, 14 May 2026 16:53:54 +0000

I Built Reusable Claude Code Skills to Ship Production Websites Faster

Most AI-generated websites don’t fail because the homepage looks bad.

They fail because all the boring production details get skipped.

Things like:

SEO metadata
prerendering
analytics
social share images
CSP headers
Lighthouse optimization
mobile polish
sitemap generation
robots.txt
deployment configuration
IndexNow
caching
environment setup

The actual React components are often the easy part now.

The operational infrastructure is what still slows everything down.

After building a few AI-assisted projects with Claude Code, I realized I was repeatedly solving the same problems over and over again. Not just visually, but operationally.

So instead of writing larger prompts, I started building reusable Claude Code skills.

The result became an open source repository of production-oriented workflows:

senternet-site-skills on GitHub

The repository contains reusable production-focused skills for things like SEO, prerendering, mobile optimization, social sharing, CSP configuration, Lighthouse tuning, analytics setup, deployment workflows, and more.

The Problem With “Vibe Coding”

I actually like AI-assisted development.

A lot.

Claude Code is incredibly powerful for:

rapid iteration
frontend generation
restructuring layouts
writing utility code
integrating APIs
content scaffolding

But after the initial excitement wears off, a pattern emerges:

The AI can generate pages faster than you can operationalize them.

You end up spending huge amounts of time fixing:

SEO issues
deployment inconsistencies
broken metadata
poor mobile behavior
missing analytics
performance regressions
social preview problems
incomplete production setup

And ironically, these are often the least exciting tasks for humans to repeatedly perform manually.

That made them perfect candidates for reusable skills.

From Giant Prompts to Reusable Workflows

At first, I tried solving this with increasingly large prompts.

Things like:

“Please make sure this page is mobile responsive, optimized for SEO, uses prerendering, has proper metadata, social sharing support, CSP headers, analytics integration, and production-safe deployment settings…”

That approach quickly became unreliable.

Claude would focus heavily on one instruction while quietly ignoring another. Sometimes it would partially implement features. Other times it would regress working functionality while trying to “help.”

The breakthrough came when I stopped treating prompts like conversations and started treating them like infrastructure.

Instead of giant prompts, I created focused reusable skills:

senternet-site-metatags
senternet-site-prerender
senternet-site-mobile-optimize
senternet-site-share-images
senternet-site-csp
senternet-site-lighthouse
senternet-site-indexnow
senternet-site-firebase

Each skill had:

narrowly scoped responsibilities
deterministic expectations
operational guardrails
reusable implementation logic

The outputs became dramatically more stable.

The Most Important Idea: Operational Consistency

One thing I learned very quickly:

AI is surprisingly good at generating components.

It is much worse at consistently maintaining production infrastructure across multiple projects.

Humans naturally remember things like:

“Did we set OpenGraph tags?”
“Are we prerendering this route?”
“Did we configure robots.txt?”
“Will this social image crop correctly?”
“Are Lighthouse scores still acceptable?”
“Did analytics get added to the production layout?”

AI often forgets these details entirely unless explicitly guided.

That’s where reusable skills become powerful.

Instead of depending on memory or repetitive prompting, operational standards become encoded into reusable workflows.

The goal wasn’t full automation.

It was reducing forgotten work.

The “Uber Skill” Concept

One of the most useful patterns ended up being what I started calling “uber-skills.”

Instead of handling a single isolated task, these workflows orchestrate multiple setup steps together.

For example:

detect what’s already configured
skip completed setup
identify missing production features
apply only incremental improvements
avoid destructive rewrites

That last point became especially important.

One of the biggest failure modes with AI coding tools is:

asking for one change and getting an accidental full-project refactor.

The skills helped constrain that behavior significantly.

---
name: senternet-create-site
description: Orchestrate the full Senternet site build by running foundation, favicon, SEO, analytics, prerender, image, and performance skills in order.
---

# Create a Complete Optimized Marketing Site

Spin up or upfit a fully optimized marketing site by executing all site skills in sequence.

---

## Mode Detection

Before asking anything, check whether the user provided a path to an existing directory:

- **Existing directory** — run in **upfit mode**: navigate to that directory and detect what's already implemented before each step. Skip steps that are complete, patch steps that are partial.
- **No directory provided** — run in **create mode**: ask the intake questions below and build from scratch. If the user does not have a design zip, directory, or HTML export, default to a barebones Hello World site using the requested project and directory names.

## Upfit Feature Inventory

In upfit mode, surface a visible feature inventory before the optional phases so the user can see what is already enabled and what is still available to add.

- For each optional capability, detect whether the repo already has it.
- Report each one as either `enabled` or `available`.
- If one or more optional capabilities are `available`, present them to the user as a single enablement menu instead of separate yes/no prompts.
- Only offer options for capabilities that are not already enabled.

Optional capabilities to inventory in upfit mode:

- Transactional email via Resend
- Reddit pixel for ad campaigns
- Spanish `/es/` multilingual support
- Ad landing pages for paid campaigns
- SEO blog
- Competitor comparison / alternative pages
- reCAPTCHA Enterprise protection for forms

What Actually Improved

The biggest gains weren’t:

writing code faster
generating prettier components
reducing typing

The biggest gains were:

fewer regressions
fewer forgotten deployment details
fewer SEO mistakes
fewer repetitive setup tasks
more consistent production readiness
reduced decision fatigue

In other words:

The AI became more useful once the workflow became more structured.

Real-World Usage

These workflows eventually became part of the production process behind projects like:

Both projects benefited from repeatedly applying the same operational standards:

metadata handling
mobile optimization
share image workflows
SEO structure
deployment consistency
performance optimization

Without reusable skills, I found myself re-solving the same infrastructure problems on every project.

Where AI-Assisted Development Still Struggles

Even with reusable skills, there are still clear limitations.

Claude Code can still:

over-refactor working code
hallucinate architecture decisions
regress responsive layouts
invent unnecessary abstractions
partially apply instructions
miss subtle UX inconsistencies

And frontend polish still requires human judgment.

A lot of human judgment.

But structured workflows dramatically reduce the chaos.

My Current Take

I increasingly think the future of AI-assisted development looks less like prompting and more like operational engineering.

The developers getting the best results probably won’t be:

the people writing the longest prompts
the people trying to remove all constraints
the people chasing fully autonomous agents

It’ll be the people building:

reusable workflows
constrained systems
composable tooling
deterministic infrastructure
operational guardrails

The real leverage comes from encoding consistency.

Not just generating code.

Final Thoughts

AI coding tools are already extremely capable.

But there’s still a huge difference between:

generating a demo

and:

repeatedly shipping production-ready websites.

For me, reusable Claude Code skills became a way to bridge that gap.

Not by replacing engineering discipline.

But by making it easier to apply consistently.