The one-person software factory

Original state

Good build ideas came from everywhere (email threads, chats, meetings, newsletters), and each one started from a blank editor. Requirements lived in my head, guardrails were applied inconsistently, and there was no single place to see what was asked for, what was built, or who approved it.

What I built

A private repository that turns every build request into the same governed path:

Issue (intake) → spec → coding agent → pull request → human review → merge

1. Intake. I capture the request, from any channel, in one structured issue form: problem, users, data sources, acceptance tests, and guardrails. The form itself warns: no secrets, no customer names, sample data only.
2. Spec. I write a short Markdown spec for each build and link it from the issue.
3. Coding agent. I assign the issue to GitHub Copilot's cloud agent. It works in its own branch and follows one repo-wide instruction file: TypeScript + React (Vite), a visible Light/Dark/Auto toggle, Segoe UI and a blue accent, tests and a README for every build, and config in environment variables.
4. Pull request. The agent opens a small PR that references its issue.
5. Human gate. A CODEOWNERS file requests my review on every PR, and I review each one before merging. (Turn on branch protection if you want that enforced.)

The first real build through the factory was a sample-data Copilot Credits sizing planner. Its pull request went from opened to merged, with tests, in under 90 minutes.

Designed value

• Every build has a paper trail: request → spec → PR → review.
• Guardrails are written once (in the issue form and agent instructions), not remembered per project.
• The agent does the typing; a person keeps the judgment.
• One look and feel across builds, so prototypes are demo-ready on day one.
• Builds land as static apps that can run on Microsoft Copilot Managed Runtime (preview) or any static host.

Human controls

• Every pull request is routed to me for code-owner review; I do the merging.
• Issue-first by practice: every build starts from a build-request issue.
• Sample data only; no tenant connections in builds.
• Labels make state visible: build-request, spec-ready, in-progress, needs-review, blocked.

Try the pattern (about 15 minutes)

You'll need a Copilot plan with the cloud agent enabled. You don't need my repo, only three files in any GitHub repo you own:

1. .github/ISSUE_TEMPLATE/build-request.yml: an issue form with problem, users, data, acceptance tests and guardrails.
2. .github/copilot-instructions.md: your stack, design rules and "never commit secrets or customer data".
3. .github/CODEOWNERS: * @your-handle, plus a branch rule requiring code-owner approval.

Then open an issue with the form and assign it to Copilot.

Public products referenced

• GitHub Copilot cloud agent (see GitHub Docs for plan availability): https://docs.github.com/en/copilot/concepts/agent-capabilities/about-agents/about-github-copilot-agents
• Microsoft Copilot Managed Runtime (preview): https://learn.microsoft.com/en-us/microsoft-365/managed-apps/?view=o365-worldwide