How Obert built a software factory it can trust on Islo

How AI-native startups win

Small AI-native startups do not win by matching the headcount of larger competitors. They win by building systems that let a small team operate with more capacity.

A software factory is the system that takes a task from intent to tested, reviewable software. It is more than a coding agent. Agents get prepared environments with the codebase, tools, dependencies, and services they need. Work moves through implementation, review, and verification. Evidence comes back, and people make the consequential decisions. Once the workflow is defined, the next task can enter the same loop without someone rebuilding the setup or carrying context between tools.

Assaf Ben Josef describes a complete version of this loop in How we stopped working for our agents, where a Linear issue moves through implementation, review, verification, and feedback until the result is ready to merge. While the factory handles these loops, the team can stay focused on go-to-market, user research, customer support, and the decisions that make the company better.

“How can I optimize these 10 or 12 hours a day that nobody works? If I’m able to leverage them more than my competitors, then I can bring a better product to market.”

Matan Kleyman, founder of Obert

Obert is applying this model to its own product development. Obert provides GTM infrastructure that monitors LinkedIn activity, finds and scores potential buyers, and supports campaigns and outreach. Its founder, Matan Kleyman, is competing with companies he describes as roughly two orders of magnitude larger.

Obert’s engineering advantage comes from extending development beyond the hours Matan is at his keyboard. Its software factory keeps product work moving while he talks to customers, runs go-to-market, and works on the rest of the company.

A software factory expands a small team

The point of a software factory is not to remove people from product development. It is to divide the work more effectively.

Agents can take on tasks with a clear objective and a verifiable result. People keep the work that requires customer context, product judgment, prioritization, and accountability. The factory connects the two: a task goes in, the agent performs the implementation, evidence comes back, and a person decides whether the result is good enough.

That workflow should not depend on a founder sitting at a particular laptop. A bug report or product idea can arrive during a customer conversation, from a phone, or outside normal working hours. If the task is well scoped, the founder should be able to start it immediately and review the result later.

For Obert, this means turning hours when Matan is focused elsewhere, or not working at all, into additional engineering capacity. He is not trying to automate every product decision. He is building a system that moves known work forward without requiring his synchronous attention at every step.

Agents need computers

“Islo gave me a predictable way to run my entire development setup the same way I’d been doing it on my local infrastructure.”

Matan Kleyman, founder of Obert

This model requires more than access to Claude.

A coding agent can reason about a task and write code. To finish real engineering work, it also needs a computer: somewhere to clone the repository, install packages, run services, inspect failures, execute tests, and preserve the context required to verify the result.

A standalone Claude instance does not provide that complete development environment. Without one, the agent may produce code, but a developer still has to move the work into the real setup, run the product, and find out whether the change actually works.

Matan encountered this gap while trying to delegate development remotely. He tried several tools and tried assembling the setup himself. The missing piece was a stable, programmatic way to give coding agents Obert’s development environment and let them complete the same loop he trusted locally.

Islo provides the agent computers and runtime infrastructure beneath Obert’s software factory. Obert uses that infrastructure to build a factory specific to its product and process: its repositories, dependencies, tasks, verification requirements, and approval points.

This separation matters. Islo does not decide how Obert should build software. It provides the computer layer that lets Obert turn its own development process into agent workflows without also building and operating the underlying sandbox infrastructure.

Start with work that is easy to verify

A software factory should not begin with “let the agent build anything.” It should begin with tasks that have:

1. A clear trigger.
2. A bounded objective.
3. Known dependencies.
4. A result that can be tested.
5. A human approval point.

“Even more than saving time, not needing to leave the work we’re focused on just to fix a button or a small piece of code that broke was the real change.”

Matan Kleyman, founder of Obert

Customer-reported bug fixes fit that pattern for Obert.

Before the factory, a message about a broken button forced Matan to stop his current work, load the development context, implement the fix, push it, and verify it. The code change might be small, but the interruption pulled him away from customers, go-to-market, or whatever higher-value problem he was working on.

In the Islo-backed workflow, a coding agent handles the implementation in a prepared computer and returns a pull request. Matan still reviews the result and decides whether to merge. The factory removes the mechanical work from his critical path without removing human judgment from the release decision.

Matan describes some customer-facing fixes as taking “a matter of minutes.” That is not an average or a guarantee. The important change is that a recurring interruption became a defined workflow that could be started remotely, completed asynchronously, and verified before shipping.

The payoff is focus

For a small startup, engineering capacity matters. Founder attention matters more.

Every hour spent reconstructing a routine development context is an hour not spent talking to users, improving the product direction, supporting customers, building distribution, or solving the problems that do not yet have known answers.

A useful software factory protects that attention - you have agents handling well-understood implementation work while the founders stay close to the market and return when judgment is required. Work can continue outside the founders’ coding hours without pretending that the company runs autonomously or that every task belongs with an agent.

Obert’s approach is a loop, not a maturity model. Start with work you understand, prove the system on it, then feed the next workflow into the factory.

For Obert, that first loop was customer-reported bug fixes. The work was bounded, the setup was known, and the result was easy to review. Once it reliably returned tested pull requests, the same pattern could move into go-to-market engineering: a new ICP becomes a campaign, the result comes back for review, and a proven process becomes the starting point for the next workflow.

Building a software factory remains an ambition for many small teams. In such a competitive market, being able to leverage LLMs to automate engineering tasks is arguably a team’s best opportunity to punch above its weight. Want to start building your own? Drop us a line at hello@islo.dev.