Stop reviewing the development plan

A friend sent me a software development plan.

He runs a nonprofit I know well. Another firm had offered to volunteer some development help, and he wanted a few technical people to look at their plan before a group call.

I read it and immediately felt stuck.

Not because the plan was bad. It looked like what a competent team would produce after being asked for a development plan in 2026. I could also tell AI had probably helped write it, which is not a criticism. I use AI to write and structure plans constantly.

But that changed how I wanted to respond.

The plan itself was not the thing I most wanted to review.

Five years ago, a development plan carried more signal. It told you something about the team, the level of effort, the likely cost, the sequence of work, the assumptions underneath the build, and whether the proposed software was plausible. It was worth gathering smart people to interrogate the artifact.

Now a lot of that artifact is cheap to produce.

A good model can generate a reasonable feature breakdown. It can outline milestones. It can identify risks. It can propose a stack, draft tickets, write acceptance criteria, and make the whole thing sound sober and professional.

That does not make the plan useless. It just means the plan is no longer where the highest-value questions live.

The useful review has moved upstream to the problem and downstream to the build system.

Start with the problem

The first thing I wanted to know was not whether the development plan made sense. I wanted to know what problem had been given to the team.

What did my friend tell them he needed? What pain was the organization trying to relieve? What work was broken? What had they already tried? What else was competing for attention inside the nonprofit right now?

Then I wanted to go one level higher.

Is this the most important problem to solve?

That question has always mattered, but the penalty for skipping it is different now.

When software was expensive, slow, and organizationally painful, the cost of building the wrong thing was obvious. You could feel the weight of the decision. Budget meetings, vendor selection, timelines, scopes, procurement, and implementation risk all forced some amount of seriousness.

When software gets easier to summon, the friction disappears before the judgment improves.

That is dangerous.

It becomes much easier to build something plausible for the wrong problem. The artifact will look real. The demo will work. The plan will read well. Everyone will feel like progress is happening because there is a thing where there used to be no thing.

But the real question is still whether that thing deserves to exist.

For an organization that does not live and breathe software, this is the transition to make.

Do not start with what can be built.

Start with what needs to change.

The right first meeting is not a technical review of the plan. It is a business review of the problem.

The other shift is deciding which questions deserve ceremony.

Some software decisions are still one-way doors. Security, privacy, data ownership, anything involving children, money, or irreversible commitments. Slow down there.

But a lot of product decisions are two-way doors now. You can build a small version, put it in front of the operator, see what it fixes, and throw it away if it teaches you that you were wrong.

That changes the meeting. The question is not whether you can produce a complete enough plan to begin. Sometimes the question is what the smallest useful thing is, and who has time to react to it.

Because shipping is not the challenge anymore. Shipping something thoughtful and useful is.

Then inspect the build system

The second question I had was not whether the proposed team could code. I wanted to know how they were going to build.

Which models are in the loop? Which coding environments? What kind of validation harness exists? How will they test the work? How will they review generated code? How will they catch regressions? How will they decide when the model is making convincing nonsense? How will they document decisions so the organization is not dependent on one helpful volunteer or one external shop forever?

That is where the real competence shows up now.

The applications I could build a year ago were already astonishing compared with traditional software development. What I could build as an individual felt unreasonable. But the workflow has changed again.

The difference between a casual AI-assisted build and a serious AI-assisted build is not just model choice. It is the whole system around the model. The prompts, tests, review loops, context, deployment flow, error handling, product judgment, and willingness to throw away a working feature because it solves the wrong problem.

That is the new technical due diligence.

Not just "can this team build the app?"

More like "does this team have a system for steering software into the shape the organization actually needs?"

Those are different questions.

The old bargain is breaking

A lot of organizations have lived with bad internal software because the alternative was worse.

You hired a vendor. They built a system. It did half of what you needed, kind of. The workflows were awkward. The reporting was brittle. Changing anything required a scope conversation.

But the thing existed, and existence used to count for a lot.

So people adapted themselves to the software.

They exported CSVs. They kept side spreadsheets. They added manual checks. They trained new staff on the weird parts. The business bent around the tool because rebuilding the tool was not realistic.

That bargain is breaking.

I am seeing it with another organization right now. They have a system that outside developers built over years. It does many of the things the business needs. It also makes many ordinary changes harder than they should be.

The shift is not simply that AI can help build replacement software. The shift is that they can start thinking from the business outward again.

What is the workflow? What does the team actually need to see? Which exceptions matter? Which handoffs create risk? Which reports are used to make decisions? Which screens exist only because a vendor's template made them convenient?

Those questions are newly practical. They let you ask software to conform to the business, instead of making the business conform to the software.

That is the part I want more leaders to understand.

AI does not mean every nonprofit director, founder, or operator needs to become a software engineer. It does mean they need to become more demanding about the relationship between their work and their tools.

The standard should go up, not down.

What I would ask instead

If someone sends you a development plan now, I would still read it.

I just would not start there.

I would start with the questions the plan cannot answer on its own.

What problem did you ask them to solve?

Why is that the problem that deserves attention now?

What would change in the organization if this worked?

What current workaround proves the pain is real?

Who will own the system after the first version ships?

What parts of the workflow should the organization understand well enough to change later?

What tools, models, tests, and review loops will the builders use?

How will the team know when the software is correct?

How will the organization avoid becoming dependent on the builders?

Those answers matter more than the polish of the plan.

We are not in a world where software is free. Good software still takes judgment, taste, care, testing, maintenance, and responsibility. Real engineering still matters. Security still matters. Accessibility still matters. Data modeling still matters. People can still create fragile messes faster than ever.

But we are in a world where the ability to produce software is less scarce than it used to be.

That changes the review.

The scarce thing is not the plan.

The scarce thing is knowing what should be built, why it should be built, and how to create enough internal fluency that the organization is not trapped by the next version of its own software.

That is the adjustment I am still learning to make.

Do not let a polished plan end the conversation. Treat it as the beginning of a better one.

When software becomes easier to summon, the work does not get less serious. The seriousness moves.