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:

  1. Defaults instead of debates. We settled the tools and conventions once, wrote them down, and stopped relitigating them.
  2. One page of thinking before code. Short, plain-language, written for the person who will read it in six months.
  3. 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.
  4. 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.