How to Run a Software Build Without Becoming a Project Manager

The owner of a Surabaya manufacturing SME once described what he thought going wrong on his custom software build: “I’m spending half my week refereeing meetings between my staff and the vendor. I didn’t sign up to be a project manager.”

He was right. He shouldn’t have to be one. The build was poorly structured, and he was paying for that with his time.

Here’s how to run a custom software project as the business owner without ending up as the de facto PM.

What you should be doing

Three things, well:

1. Defining what success looks like. Not the features — the business outcome. “Cut order processing time below 60 seconds.” “Reduce monthly reporting work to under 4 hours.” Without this, every decision becomes about preference instead of outcome.
2. Approving scope changes. When the vendor or your team wants to add or remove something, you decide based on whether it serves the success metric. This is a 5-minute decision per change, not a meeting.
3. Acceptance at milestones. Every 2–4 weeks, the team demos progress. You verify it’s tracking toward the success metric and approve moving to the next phase.

That’s it. Each takes a few hours per month, total. If your time investment is bigger than that, the project is structured wrong.

What you shouldn’t be doing

Five things owners commonly get sucked into and shouldn’t:

• Daily standups. You don’t need to be in them. The team uses them; they don’t need an audience.
• Mediating between staff and vendor. That’s the job of whoever’s running the project on either side. If they can’t talk to each other directly, that’s a problem to fix, not a meeting to attend.
• Reviewing detailed designs or wireframes. The lead user (the person who actually does the work the software supports) reviews these. Their judgment beats yours on workflow specifics.
• Triaging bugs. That’s the team’s job. You see bug reports as summary numbers, not individual tickets.
• Picking technical implementations. “Should we use library X or Y” is not your decision.

If you find yourself doing any of these regularly, the project structure is broken.

The structure that protects your time

What needs to be in place from week one:

A single owner on each side

One person on the vendor’s side owns the project. One person on yours does too. This second person isn’t necessarily a PM — they’re often the lead user or operations head. But they have authority to make day-to-day decisions and represent the business in conversations.

The two owners talk to each other directly. You’re consulted only when decisions exceed their authority.

Clear escalation criteria

Define what comes to you vs what doesn’t:

• Comes to you: scope changes worth more than X hours of work, budget overruns, hire/fire decisions about team members, decisions that affect business strategy.
• Doesn’t come to you: technical implementation choices, day-to-day prioritisation, design details, bug triage.

When something is unclear, the default should be “the owners decide and inform you”, not “escalate.”

A weekly written update, not a meeting

15-minute writeup once a week. Three sections: what shipped, what’s blocked, what decisions are needed from you. You read it in 5 minutes. If everything is on track, you don’t reply. If something needs your attention, you reply.

This single practice replaces 80% of the meetings owners get pulled into.

Demo cadence, not deadline cadence

Every 2–4 weeks the team demos working software, not slides. You verify the demo against the success metric, approve or course-correct.

Demo cadence keeps everyone honest. It’s hard to fake progress when you have to show working software every two weeks.

Red flags during the build

Things that mean the structure is breaking down:

• You’re being asked to make small decisions multiple times a week. Means the owners-on-each-side structure isn’t working. Fix it before continuing.
• Status updates are slide decks instead of working software. Means there’s nothing working yet. Get a demo.
• The team avoids putting things in writing. Means accountability is being avoided. Insist on written updates.
• Decisions made in meetings get re-litigated next week. Means the decision-making authority isn’t clear. Spell it out.

The owner mindset that works

Two mental shifts that help:

• Treat the team like a contractor building a house. You don’t tell them how to mix concrete or which order to install fixtures. You inspect at milestones and accept or reject.
• Your job is the “why”, not the “how”. When you find yourself in a “how” conversation, ask “what business outcome does this serve?” If you can’t answer, you’re in the wrong meeting.

If you’re approaching a custom software project and want to set it up so you stay in your lane, an hour of conversation usually clarifies the right structure for your specific situation. We do those at no cost.