When you manage software work for more than one client at a time, the hard part is not writing the code. The hard part is knowing what to build, in what order, and catching the things that need a human decision before they ship.
We have been building what we call the Software Factory at Miaigi for the better part of this year. This is the first post in a series about what we have learned. It starts with the thing that surprised us most: how much a proper approval workflow for software development changes the day-to-day.
The problem with doing it all in GitHub
GitHub is where the code lives, and it is excellent at that. But when you are running work across several clients, each with their own repo, issues, and pull requests, GitHub alone is not enough.
The friction shows up in small ways. A pull request needs review before it merges. Another client has an issue that needs a pricing decision. A third client wants a new feature and you need to decide whether to take it on. All of those decisions are scattered across repos, inboxes, and chat threads.
You end up context-switching constantly. You check GitHub for PRs, switch to email for client requests, switch back to GitHub for issue comments, then try to remember which client needed what by when. It works when you have one client. It starts to break at three. It is unsustainable at five.
What we built
We added an approvals workflow to our internal management site. When something needs a human decision (a pull request to review, a client request to approve, a pricing choice to make), it surfaces there as a single card with context, a suggested course of action, and a clear approve or reject button.
No more hunting through GitHub notifications. No more forgetting a PR that has been sitting open for three days. Everything that needs a decision lands in one inbox, and nothing merges until it has been explicitly approved.
The flow is simple:
- An agent or a client raises something that needs a decision.
- It appears in the approvals inbox on our internal management site, with the relevant context and a recommendation.
- We review, approve or reject, and add notes if needed.
- On approval, the factory picks it up and carries it through: merging a PR, creating an issue, or moving a request into implementation.
For pull requests specifically, this has been the biggest change. Instead of reviewing PRs inside GitHub's interface, we see them as approval cards with a summary of what changed, what issue it closes, and a recommendation. We approve from one place. The factory handles the merge.
Managing multiple clients effectively
Before this workflow, managing five clients meant keeping fifteen browser tabs open and hoping nothing fell through the cracks. Now, every decision across every client surfaces in the same inbox.
That sounds like it would be overwhelming, but the opposite happened. Because each approval card comes with context and a recommendation, most decisions take ten seconds. Approve, move on. The ones that need more thought are easy to spot because they come with more detail.
We stopped losing things. We stopped duplicating work. And we stopped spending evenings catching up on PRs we forgot to review during the day.
The Alpha Fire pilot: letting clients raise their own requests
The next step was obvious. If the approval workflow works for our internal decisions, what if clients could put requests straight into it?
We are piloting this with Alpha Fire Electrical right now. Callum, who handles their day-to-day requests, can log in to his own website, click Edit, and change the wording or add a photo in place. That change becomes a request for change, an RFC, in our approvals inbox.
It works like this:
- Callum makes the change on his own site, much as he would edit a document.
- It lands in our approvals inbox as an RFC card with the details.
- We review it, approve or reject, and add notes if we need clarification.
- On approval, the factory raises the GitHub issue, builds the change and ships it through the same checks as any other work.
Nothing reaches GitHub until we have approved it, and nobody on our side has to turn an email into a ticket. The request goes in, we approve it, and the factory takes it from there.
That is a big deal for a small business client. They do not need to understand GitHub or write a ticket in a particular format. They change their own site, and the system does the rest, with a human checkpoint on our side before anything gets built.
What comes next
The Alpha Fire pilot has been running well enough that we are preparing to roll the RFC capability out to every Miaigi client. That means any business working with us will be able to submit change requests through the same approval-driven process.
For clients, the benefit is simple: a clear, fast way to request work without email chains or phone tag. For us, the benefit is that every request arrives in a consistent format, goes through the same review checkpoint, and moves into implementation without manual handoffs.
What this means for small businesses
Most small businesses do not need a complex project management tool. They need a way to ask for something and trust that it will be handled. The approval workflow gives them that, and it gives us a way to manage it without losing track.
That is the point of the Software Factory. Not to replace humans, but to make sure the human decisions are the ones that actually matter, and to automate the rest. If you are spending your evenings reviewing pull requests and chasing client emails, there is a better way to do this. If you want to see how it could work for your business, get in touch.
