Custom software has crossed an economic threshold. For years, the default advice was to buy a subscription and adapt the business to out-of-the-box software. Custom systems built around a company's exact operations cost too much for most mid-market companies.
In a recent customer conversation, I put the change plainly: Two or three years ago, many critical operational systems were out of reach. Today, a growing class of them can make financial sense.
Agentic engineering, or AI-assisted development, changed the math. It has reduced the time and cost of implementation, but requirements, adoption, security, and quality still determine whether a system works.
A small engineering team can now plan, build, test, and review more software in less time while keeping people responsible for scope, quality, and approval.
That matters because off-the-shelf software never fits an operation perfectly. The remaining gaps often contain the hardest work: reconciling invoices across properties, managing order exceptions, encoding tribal knowledge as business rules, and connecting systems that were never designed to work together.
Reconfiguring a business around a piece of software creates two risks:
- The company ends up with more software.
- The company changes the very things that make its operation unique.
Intrinsic Labs is an AI operating partner for mid-market operators. We use an internal delivery system called Labs Flow to turn operating knowledge into custom agents and software that run inside each customer's existing workflows.
Labs Flow connects customer conversations, structured requirements, design iterations, implementation, automated tests, structured reviews, and human approval. It turns what we learn from customers into scoped requirements, tested code, and a pull request that a person approves.
Conversations are executable
We found that production slowed whenever our team had to manually translate each conversation into requirements. We redesigned that handoff first.
Operational requirements rarely arrive in a clean document. They emerge during conversations with the people doing the work. One person explains the normal process. Another remembers an exception. A manager corrects the rule.
The team may also discover that two departments use the same word differently. A forward-deployed engineer asks questions until the requirement is precise.
Most of the useful information lives in these details. It takes time and careful planning to capture the context.
We keep records of our conversations. A series of agents extracts direct requests, implied needs, business rules, technical constraints, risks, unresolved questions, and the source statements behind them.
The agents compare each finding with the project's existing context so we do not duplicate work. As our understanding changes, they update the documentation with it.
People still make the product decisions. A workflow owner defines what success means, and our team decides what belongs in scope. The agents reduce context loss and give every later decision a traceable starting point.
A customer conversation can now start the build process without becoming a vague ticket or a drawn-out scoping exercise. The extracted rules, constraints, and unresolved questions become inputs to planning.
What the software factory does
A coding agent can write code. A software factory manages everything around that code: context, scope, dependencies, testing, review, security, and stopping conditions. The system is a graph of work with explicit dependencies and gates.
Labs Flow moves a feature through four stages:
- Brainstorm the behavior, primary user, success criteria, constraints, and non-goals.
- Turn the requirements into implementation units with explicit dependencies, file boundaries, test scenarios, and verification criteria.
- Build non-overlapping pieces in parallel, each in an isolated copy of the code.
- Combine the pieces, run the full test and security checks, and submit the change for human approval.
Different models take on distinct roles across the process, creating checks between planning, implementation, and review. One model drafts and revises the plan, while another challenges its assumptions before implementation begins in bounded units. Separate reviewers examine correctness, maintainability, testing, project standards, and security before a final reviewer reads the merged change as one system.
Subagents working in parallel shorten elapsed time. File-collision checks protect the branch. Test-first development forces each unit to prove the intended behavior. Failed units get another bounded attempt instead of quietly moving forward.
The flow stops at an open pull request. A person still decides whether the change is ready to enter the customer's system.
The factory improves itself
Labs Flow also helps us improve Labs Flow. Each use exposes missing checks, slow handoffs, and lost context. Those observations become requirements for the next release.
The initial version shipped with five core commands. Actual use exposed the next set of needs. Within eight weeks, the system had added test-first enforcement, isolated parallel execution, structured review workflows, security checks, visual planning, automatic retries, and a live progress dashboard.
Each addition came from watching the factory work. We saw where context disappeared, execution slowed, risk accumulated, and work waited too long for a decision or review. Then we used the same machinery to improve the machinery.
The customer loop works the same way.
A conversation produces requirements. The factory produces software. Real use reveals corrections, exceptions, and new opportunities. The next conversation captures that operating knowledge, and those corrections become requirements, evaluation cases, and tests for the next release.
The software gets better because operating the factory continuously teaches it.
Why the economics changed
Cheaper code only matters when quality and adoption are maintained. Traditional custom development concentrates cost in translation, coordination, rework, and quality assurance. The software factory compresses each of those areas.
Recorded conversations and structured requirements reduce context loss and interpretation drift. Parallel implementation shortens cycle time, while automated tests and independent reviews catch failures before customers see them.
Reusable connectors reduce the net-new work in later deployments. Traceable documentation also helps future agents avoid repeating known mistakes.
That changes which projects make sense. We tell clients to focus on what makes their business different. Do not rebuild a CRM or a note-taking app. Rebuild something core to the business that competitors cannot buy off the shelf.
A mid-market operator can now consider custom software for a workflow that is too specific for horizontal software and too valuable to leave in spreadsheets. Examples include invoice reconciliation, quoting, scheduling, exception handling, compliance review, prospecting, and document-heavy customer service.
Every project needs a measurable definition of success. Depending on the workflow, that measure might be cycle time, throughput, error rate, review hours, service level, or margin.
We measure each deployment against a defined baseline and target. The software factory increases our capacity to deliver, but the outcome still depends on forward-deployed discovery, brownfield systems work, human review, adoption, and KPI-gated delivery.
Mid-market operators should start with a workflow that limits throughput or creates avoidable errors. The strongest candidates are company-specific processes where better software can increase capacity, protect quality, or improve margin.
Possibilities on the frontier
What we are experiencing on the frontier is a shorter path from operational knowledge to owned software and business outcomes.
Our customers keep their company-specific knowledge under their control. The workflow logic, evaluation cases, and reviewed corrections remain durable assets even as the underlying models change.
The resulting software fits the operation more closely because it grows from the operation. Every handled exception, reviewed correction, and added test strengthens the next release.
We improve our delivery system and reusable, non-confidential building blocks across engagements. The learning loop makes future deployments faster without turning one customer's operating knowledge into someone else's product.
If your team stopped considering a workflow because custom software sounded too expensive or too specific, that assumption is stale.
Start with one workflow where manual coordination limits throughput. Bring its current volume, labor hours, error rate, exception rate, and system dependencies. Define the target and acceptance test, then compare the value of that improvement with the cost of building and operating the system.
That is what the software that builds our software makes possible.