Skip to main content
Navigation

Run it in-house first? Write down what that cannot answer

Whether to run it in-house first depends on the kind of question in-house running can answer.

Key points

  • In-house only answers whether it runs
  • Whether anyone pays stays unanswered
  • Split answerable and unanswerable first
  • Date the handover; do not polish forever
Whether to run it in-house first depends on the kind of question in-house running can answer.
A diagram of this article’s key points.
Contents

Running it in-house answers whether it works, and little more

A&A perspective

The new thing you are about to sell outside is what this article calls the offering. Running it in-house means putting that offering to work in your own company first.

A&A perspective

Building the next thing for your own use is fast and it feels good. The person asking and the person building are the same, so there is no specification to confirm. If it breaks, the only one inconvenienced is you, so there is nothing to fear.

A&A perspective

Even so, the range of questions this approach answers is narrower than it feels. What gets answered is whether it works, where it breaks, and how much hands-on time each week it takes to keep running. All three are things you can observe at your own desk.

From the sources

An article Gumloop published about its own support operation is an example of that range. Gumloop is a company that provides tooling for assembling workflow automation.

Gumloop ↗

From the sources

Dated 17 February 2026, the article says the team built its support operation using the same tools available to every Gumloop user. Not special internal features, but only the building blocks any user has: the article states that condition plainly.

Gumloop ↗

From the sources

The same article says the support team has only two people. The figures at the head of the article state that over 500,000 support-related workflows run every week. That is the company's own claim, and the article does not say what was counted or how it was measured.

Gumloop ↗

A&A perspective

So we do not take those figures as numbers any company would reach.

A&A perspective

What can be read from this article stops at: a way of building that also holds up in Gumloop's own business. Whether anyone outside would buy that way of building is not something the same article can tell you. It did not observe whether such buyers exist.

Whether anyone else pays gets no answer in-house

A&A perspective

Two questions get no answer from running it in-house: whether anyone else will pay money, and whether other people's input has the same shape as yours.

A&A perspective

Neither can be observed without people outside. You know every part of the offering, so your input never varies. You are the one with the problem, so the moment where someone weighs up whether to pay never arrives.

From the sources

Anthropic's published case study of Chatbase carries a record bearing on both questions. Chatbase is a company that provides a way to automate corporate customer support with AI.

Anthropic ↗

From the sources

According to the page, Chatbase treated itself as its own first customer. From that position, the page says, the team found that beyond handling routine inquiries it could also surface customer sentiment and product feedback.

Anthropic ↗

From the sources

The same page also describes where Chatbase started: what began as a document chat interface evolved as enterprise customers pushed for more sophisticated features, arriving at its present form.

Anthropic ↗

A&A perspective

Put those two records side by side and an order appears. What in-house running found was a lead on a feature; what settled the shape of the offering was demand from outside customers. That is A&A's reading, and neither source asserts the order itself.

From the sources

Neither source states that being its own first user raised revenue or retention. The case study page does record that usage grew, but that is Chatbase's own claim, and it is not a measurement of what in-house running achieved.

Gumloop ↗Anthropic ↗

Split the answerable from the unanswerable before you start

A&A perspective

What you do before starting is write the questions into two piles: the ones in-house running answers, and the ones it does not.

Hypothetical example

As an A&A design proposal, here is a single table of four columns. It is a hypothetical example, not a record of an actual engagement.

Hypothetical example

Questions in-house running answers: whether it works, where it breaks, how much hands-on time each week

Hypothetical example

Questions in-house running does not answer: who pays, at what price, what shape other people's input takes

Hypothetical example

The handover date: the day in-house running ends

Hypothetical example

Assumptions to discard before handing over: conditions that only ever held for you

A&A perspective

Fill the first two columns before you start. Start with them blank and you will end up, after starting, trying to establish whether it will sell from inside your own usage, and only the time stretches out with no answer arriving.

A&A perspective

The fourth column, the assumptions to discard, is the hard one to write. List the premises you set to suit your own operation that will not hold for an outside customer: that the tools are all in place, that the vocabulary matches what is used internally, that the steps come in a settled order.

A&A perspective

For contract work, the difference from the two companies cited above shows up here. Both supply their own product to many users, so in-house running is itself a live example of the product. When you deliver individually to a specific customer, your own operation and the customer's operation are not necessarily the same shape. Which means the result of in-house running does not necessarily show the customer's acceptance conditions.

Set the handover date first so polishing does not become the goal

A&A perspective

Set the date you move it outside before in-house running begins. Try to set it afterwards and you will find you cannot.

A&A perspective

In-house running has no ending condition. As long as you keep using it, there is always something to fix. And since each fix makes it better, the feeling of progress continues. Without a date, the polishing itself becomes the goal.

A&A perspective

Set the date as a date. The point is not to set it as an achievement condition. With a rule like once it is usable, then outside, you are the one judging whether it is usable, so the day it goes out slides forward indefinitely.

A&A perspective

What you do on the day the date arrives is put the unanswerable questions from the second column to people outside. You ask without waiting for completion. In the source case too, the shape changed only once demand arrived from outside.

A&A perspective

One bias that in-house running brings in belongs here. You are the user who knows that offering best. Even an operation you got through without hesitating is one an outside user is likely to hesitate over. This bias strengthens the more you use it, so the longer you extend the date, the worse your position.

Summary

A&A perspective

What in-house running answers is whether it works, where it breaks, and how much hands-on time each week it takes.

A&A perspective

Who pays, and the shape of other people's input, get no answer from in-house running.

A&A perspective

Before starting, write the answerable and the unanswerable questions into two separate piles.

A&A perspective

Set the handover date as a date, not as an achievement condition.

A&A perspective

In-house running is not a substitute for validation; it is preparation before going outside. Framed that way, setting a date stops feeling like a loss.

Whether to run your next offering in your own business first is settled by the kind of question that running can answer, not by how fast it takes shape. In-house running answers whether it works, where it breaks, and how much hands-on time it takes each week to maintain. Who pays, and what shape other people's input takes, cannot be observed without people outside. So before starting, write the answerable and the unanswerable questions into two separate piles, and set the date for moving outside as a date rather than an achievement condition. In-house running is not a substitute for validation; it is preparation before going outside. On top of that, you are the user who knows the offering best, so the more you use it the wider the gap grows between you and an outside user.

FAQ

Is it wrong to skip in-house running and test with an outside customer straight away?

Not wrong. When it breaks you lose time explaining. If you can absorb that, you get your answers sooner. The dividing line is how much trust you lose when it breaks. If there is a counterpart where little is lost, starting outside is a sound approach.

How long should in-house running last?

No appropriate length can be given. A&A has not measured the days it took to go from starting in-house running to moving outside, so we offer no rule of thumb in days. What can be said about the method is only this: estimate yourself how many days are needed to establish whether it works, and write the end date down first.

What if your own operation and the customer's operation are too different?

Then the column of questions in-house running answers gets short. If the column holds only whether it works, what in-house running can do is close to a smoke test. Keep those days few and plan to put the remaining questions to people outside.

Sources & editorial note

Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.

  1. Supporting the world's most AI-native companies with a 2-person team

    Gumloop · February 17, 2026

    Accessed 2026-10-20
  2. Chatbase Claude Platform (API) case study

    Anthropic · undated case study page

    Accessed 2026-10-20

Editorial policy

← All articles