Bytefo — AI automations and cool things, built by two people.

Why we automate the boring parts first

Bytefo — Tue, 08 Sep 2026 00:00:00 GMT

Most people who contact us arrive with the same idea: build the impressive thing. A chatbot, an agent, something with a demo that gets applause in a meeting. We almost always talk them out of it, at least for the first project.

The valuable work is usually hiding underneath it — the copying and pasting, the inbox that eats an hour a day, the report somebody rebuilds by hand every Monday because the last person who knew the query left.

Boring is a technical term here

A task is a good automation candidate when three things are true:

It repeats. Weekly or more often. One-off tasks are not worth automating; you will spend longer building the thing than doing it.
It has a shape. A clear input, a predictable decision, a known destination. If the output format lives in one person’s head, that is a documentation problem first, and a code problem second.
Somebody notices when it is wrong. There is a real consequence if the automation drops a step, which means you will actually maintain it.

If a task passes all three, the economics are almost boringly predictable. If it fails one, no amount of clever model selection saves it.

The shape of the work

The pattern we build most often looks like this: something arrives, it needs to be read, classified, enriched, and sent somewhere useful.

// The shape, not the implementation: read → decide → enrich → deliver.
export async function triage(item: Incoming) {
  const reading = await read(item);            // an LLM reads messy input
  const decision = classify(reading, RULES);   // rules decide, not the model
  const enriched = await enrich(item, company); // your tools, your data
  return deliver(enriched, decision.destination);
}

Two opinions are baked into those four lines, and both of them matter more than the model choice.

The model reads; the rules decide. Language models are excellent at turning a messy email into structured fields, and unreliable at being consistently right about policy. So we let it extract, and let ordinary deterministic code decide what happens next. When something goes wrong you can read the rules and point at the line. Try doing that with a prompt.

Enrichment uses your tools. If the answer lives in your CRM, the automation reads your CRM. It does not keep a hopeful copy of your data in a separate system that drifts out of sync by week three.

Where it goes wrong

We have seen the same three failure modes enough times that we now check for them before we start.

Failure	What it looks like	What we do instead
Automating a process nobody understands	Two people describe the same workflow differently	Map it on one page first, with the people who do the work
Full autonomy on the edge cases	The 5% of odd inputs silently go nowhere	Route anything uncertain to a human queue with context attached
Building on tools the team resents	The automation works, nobody uses it	Automate inside the tools people already open every day

The second one is the expensive mistake. It is tempting to promise full autonomy, because that is the version that sounds impressive. But “the automation handles 90% and hands you the tricky 10% with a summary” is a system people trust. A system that quietly loses 5% of invoices is a system people stop using, and then you have paid for two processes instead of one.

How we measure it

Not with a benchmark. With three numbers that a non-technical person can check:

Hours back per week. Measured before and after, from the people doing the work.
Touch rate. How often a human has to intervene. This is the maintenance bill, and it should fall over the first month.
Time to answer “why did it do that?” If nobody can explain a decision in a couple of minutes, the automation is not finished.

If the only person who understands the automation is the person who built it, you have bought yourself a dependency instead of a system.

What we would do first at your company

Ask the team one question: what did you do this week that you have done before? Collect the answers, count how often each one repeats, and pick the top one. It is almost never the task that got mentioned in the strategy meeting.

Then build it small, in days, with the people who own the process watching. If it survives a month of real use, automate the next one. If it does not, you have lost a week instead of a quarter, and you have learned something true about how your business actually runs.

That is the whole trick. The flashy project is still available afterwards — it just gets built on top of a company that already has a bit more room to breathe.

Two people, one AI studio

Bytefo — Thu, 03 Sep 2026 00:00:00 GMT

Bytefo is two people. When we say that, most people politely wait for the part where we mention the team we are about to hire, or the agency we are partnering with.

There is no such part. Two is the plan.

Why small is the feature, not the limitation

Every hand-off in a project costs something. A message gets summarised, the summary loses the detail that mattered, somebody builds the slightly wrong thing, and a week goes by before anyone notices. In a big team, process exists to make those losses survivable. In a two-person studio, we can simply skip the hand-off.

The practical result is that the person who understands your problem is the person writing the code that solves it. When you describe the annoying thing on a Tuesday call, that same person can be halfway through a working version on Thursday. There is no translation layer to lose it in, because there is no layer.

We are not pretending this scales. It does not, and we do not want it to. What it does is let us take on a small number of projects and finish them properly.

The stack, honestly

We have no interest in a technology stack as a personality trait. Here is what we use and why, so you can judge whether it fits you.

TypeScript for almost everything. Automations, internal tools, glue. One language across the stack means one of us can pick up what the other started, which matters a great deal when there are only two of you.
Off-the-shelf models, treated as replaceable. The interesting engineering is the plumbing around the model: the retries, the validation, the human queue for uncertain cases. We keep that layer separate so swapping a model is a config change, not a rewrite.
Static sites and simple deploys. This site is plain HTML built from markdown, deployed as files. No database, no server to babysit, no monthly invoice for a page that changes twice a month.
Cron, webhooks, and queues before frameworks. Most automation problems are solved by something that runs on a schedule and calls two APIs in the right order. Reaching for a platform first is how you end up maintaining a platform.
Markdown and git for everything written. Decisions, client notes, this blog. If it is not in the repository, it does not exist.

The common thread: we prefer tools that a competent developer can understand completely in an afternoon. Boring tools fail in boring ways.

What we say no to

Refusing work is the most reliable quality control we have. These four are automatic no’s.

Six-month roadmaps. If a project needs a quarter before anything works, the plan is wrong, not the deadline. We would rather find the smallest version that can be in use next week and grow it from there.

“AI strategy” documents. Nobody ever needed a document about AI. They needed the Monday report to build itself.

Projects where nobody owns the process. We can automate a workflow; we cannot automate a disagreement. If two departments describe the same process differently, that conversation has to happen before we write code.

Anything we would not use ourselves. It is a small studio, so our reputation is the only marketing budget we have. Work we are not proud of is not worth the money.

Juggling four jobs with two people

Running a studio this size means each of us is doing product, engineering, writing, and support on the same day. A few things make that survivable:

Defaults instead of debates. We settled the tools and conventions once, wrote them down, and stopped relitigating them.
One page of thinking before code. Short, plain-language, written for the person who will read it in six months.
Working software before polish. A rough thing that runs tells you whether the idea is right. A beautiful thing that does not run tells you nothing.
Ship it, then automate our own job. Every repetitive task we do twice gets automated. It is both useful practice and the only reason two people can look like more than two.

Small teams do not win by working more hours. They win by having fewer places where the work can get lost.

Working with us

If you have a process that eats somebody’s week, tell us about it in a couple of paragraphs. You will get a real reply from one of the two of us, an honest read on whether AI helps here, and — if it does — a plan with days in it instead of phases.

Building in the open: our first product

Bytefo — Wed, 26 Aug 2026 00:00:00 GMT

Automations are wonderful and slightly thankless. Each one solves a specific problem for a specific team, it works beautifully, and then it is done — quietly running somewhere, saving somebody an afternoon a week, generating no further momentum.

Products are the opposite. Harder, slower to pay off, and the only thing that compounds: build it once and the hundredth user costs you almost nothing extra.

So we are building one. This is the first note in a series about it, written while it is still small enough to be embarrassing.

What we are building

The short version: an AI toolkit for the operational busywork that small teams drown in — the same category of work we automate for clients, packaged so that a team can run it themselves.

We are deliberately not naming it yet, and not committing to a feature list, because we have watched other people do that and then spend six months defending a promise they made before they understood the problem.

What we will commit to is the shape of the problem. A small team has a handful of repeating jobs: intake that needs sorting, documents that need reading, updates that need writing, follow-ups that need remembering. These jobs are individually too small to justify software, and collectively they eat a person.

Why build in the open

Two reasons, one of them selfish.

The selfish one: writing about what we are doing forces clarity. A decision that seemed obvious in a conversation turns out to have three unexamined assumptions when you try to explain it in a paragraph. We catch those in the writing, which is cheaper than catching them in the code.

The other reason is that most product writing is written backwards — after the decision, polished until it looks inevitable. That version is useless to anyone in the middle of the same problem, which is exactly where we are. So we will publish the parts that are normally edited out: what we tried first, what we threw away, and the numbers we are willing to share.

A launch post tells you what somebody wants you to think. A build log tells you what is actually true.

The rules we set before writing code

One job, done properly. The product should do a single thing well enough that people describe it in one sentence without adding “sort of”.
Ship before it is comfortable. A rough version in front of ten real users beats a polished version in front of nobody. We would rather have something live in days and improve it in public than announce a date we cannot defend.
Charge from day one. Free betas attract people who like trying things, not people with the problem. A small price is the cheapest honest signal we know of.
No roadmap promises. We will tell you what we are working on, not what will exist in March.
If a client problem keeps appearing, that is the roadmap. Our client work is the best research we have. When three teams ask for the same thing, the product should already be doing it.

What we are not doing

We are not raising money. We are not hiring. We are not building a platform, an ecosystem, or anything with a marketplace in it. Every one of those is a way to spend a year on something other than the product.

The plan is smaller and more boring than that: find the sharpest version of the problem, build it with the two of us, put it in front of people, and let what happens next decide the next step.

Following along

New posts land on the blog and in the RSS feed — no newsletter, no popup, no tracking pixel. Posts about the product will be tagged Products, and when there is something you can actually use, it will be the loudest thing on this site.

Bytefo — AI automations and cool things, built by two people.

Why we automate the boring parts first

Boring is a technical term here#

The shape of the work#

Where it goes wrong#

How we measure it#

What we would do first at your company#

Two people, one AI studio

Why small is the feature, not the limitation#

The stack, honestly#

What we say no to#

Juggling four jobs with two people#

Working with us#