We write the code ourselves.
Arc Labs is not an investor, and we do not pass work on to subcontractors. Every product on this site was designed, built and is run here. Client projects are done the same way, by the person who will also answer for them after launch. We would rather build fewer things that still work in three years than many that need replacing next year.
The pattern that repeats
01
Pick a problem you can say in one sentence
If the problem needs a paragraph to explain to the person who has it, it is not one problem yet. Dishy exists because "the dishes pile up and cleaning services want a contract" is a complete thought. Everything we take on, our own or a client’s, starts as a sentence like that.
02
Learn the domain before writing the product
For the property tax work this meant reading the statutes, county filing rules and evidence standards state by state, not skimming three competitor landing pages. For client work it means learning how their team actually works before deciding what to automate. It is slow, and it is where most of the advantage comes from.
03
Build the smallest thing a real person could use
Not a prototype and not a landing page with a waitlist. The smallest version someone can do a real task with, because that is the only thing that tells you honestly whether the idea holds.
04
Keep it, kill it, or keep it running quietly
All three are fine outcomes. A product that works and does not need daily attention should be monitored and maintained, not rebuilt to justify the effort already spent on it. The same goes for systems we hand over to clients.
What carries from one project to the next
Judgement, mostly
How long to wait before dropping something. Which technical shortcut costs you later and which one never matters. How to tell real interest from polite interest. That gets better with every project.
Not the codebase
Shared code across very different products is mostly wishful thinking. A household services marketplace and a property tax engine have little in common. Forcing them onto one codebase produces abstractions that fit neither. What does carry over is the tooling: deployment, monitoring, testing and security practice.
Where it gets hard
Running several products at once means not all of them can move every week. We handle that with a simple rule: client work is planned first, with agreed scope and dates, and our own products fit around it. A product that is working is allowed to sit still.