trolls.dev — Notes from the night shift

The map is made of open tabs

Tue, 14 Jul 2026 00:00:00 GMT

There's a default architecture for building a live map of the physical world, and it's expensive on purpose. You buy cameras. You mount them. You run their feeds back to a data center where a rack of GPUs watches every frame, and you pay for that rack whether anything interesting is happening or not. Coverage is a line item: every new intersection you want to see is more hardware, more bandwidth, more compute. The map scales with the budget, and only with the budget.

Thyseus is a live map of detected vehicles, people, and infrastructure, and it's built the other way around — the cheap way, which turned out to also be the interesting way. It buys no cameras and rents no GPUs. It runs on things that already exist and were already switched on, and getting there meant questioning two assumptions the default architecture never examines.

The cameras are already there

The first assumption is that you need to deploy sensors. You don't. Point a browser at the public web and there are already thousands of live camera feeds streaming right now — state DOT traffic cameras, port and bridge feeds, city intersection cams — publicly accessible, publicly funded, and mostly watched by no one. The physical sensing layer for a national map already exists. It's paid for. It's on.

What's missing isn't cameras. It's attention. A feed nobody is looking at is just bandwidth going nowhere. So the actual problem Thyseus set out to solve was never "how do we see the world" — the world is already on camera — but "how do we look at thousands of feeds at once without building the data center that would normally imply."

The compute is already there too

That's the second assumption, and the one that makes the whole thing work: that the watching has to happen on a server you pay for.

Every person who opens Thyseus is sitting in front of a device with a capable GPU that is, at that moment, doing almost nothing. Modern browsers can run a real object-detection model directly on that hardware — WebGL and WebGPU turned the machine you already own into an inference engine, no install, no driver, no account. So Thyseus runs the detection in the contributor's browser. Their tab pulls a public feed, runs the model on the frames locally, and the server never sees the video at all.

Every open browser tab is a sensor. We didn't build the sensor network. We noticed it was already assembled, plugged in, and idle, and wrote the software that lets it agree on what it's seeing.

This is the inversion the product is built on. In the default architecture, compute is centralized and scarce, so coverage costs money. Here compute is distributed and volunteered, so coverage costs interest. Ten people watching feeds is a small map. A thousand people watching feeds is a big one, and the bill to us barely moves, because the expensive part — looking at every frame — is happening on a thousand machines we don't own and don't pay for. The map scales with the community, not the budget.

Detections, not video

There's a detail in there that's easy to skim past and is actually load-bearing: the browser streams detections, not video. It doesn't ship frames back to us. It ships the small structured result — a car, here, now, this confident — and throws the pixels away.

That choice pays off three times over. It's cheap, because a detection is a few bytes where a video stream is megabytes a second. It's private, because raw footage of public streets never pools up on our servers; the only thing that leaves the contributor's machine is "something was detected," not the picture of it. And it's honest about what a map is for — nobody wants to scrub through a thousand simultaneous video feeds. They want to know what's where. The detection is the useful part. The frame was just how you got it.

From "on camera 12" to a point on the earth

A detection that only knows which camera saw it isn't a map, it's a list. The step that turns Thyseus from a feed aggregator into an actual map is geometry.

Each public camera has a known position and a known view. A detection arrives with a location within the frame — this car is in the lower-left, this far down. Combine the camera's placement and orientation with where the object sits in its field of view, and you can compute where the object actually is: real latitude and longitude, a pin you can drop on a shared map next to pins computed from hundreds of other feeds. A "car on camera 12" becomes "a car at this corner," which is the difference between raw footage and situational awareness.

Do that continuously, across every feed every open tab is watching, and the separate cameras stop being separate. They fuse into one surface — a single live map of a region, stitched from feeds that have no idea they're part of it.

Being honest about the seams

We'd rather show you the seams than pretend there aren't any, which is the same discipline that keeps code-results from dressing up a correlation as a proof. Thyseus is exactly as live as the tabs that happen to be open. A corner nobody is watching goes dark until someone points a browser at it. Public cameras have their own outages and blind spots. Detection at the edge trades a sliver of accuracy for an enormous gain in reach — a browser model is not a rack of A100s, and we don't claim it is. These aren't bugs to hide behind a loading spinner; they're the honest shape of a map made of volunteered attention, and the contributor leaderboard exists precisely because more attention is the thing that makes the map better.

Why a two-person studio ships something this ambitious

On paper, a live national object-detection map is infrastructure-company work — the kind of thing that usually comes with a warehouse of GPUs and a funding round to pay for them. We took neither, and we could build it anyway for one reason: we refused the architecture that would have required them.

That refusal is a habit, not a one-off. It's the same instinct behind believing the fastest page is the one already there — the cheapest sensor is the camera already streaming, the cheapest GPU is the one already glowing in a contributor's laptop. The engineering that mattered wasn't a bigger machine. It was noticing that the machine was already built, already on, and waiting in a browser tab for someone to write the software that would let all the tabs agree on what they were looking at.

That's the studio's whole bet, really, pointed at the physical world instead of a screen: most of what you'd go out and buy is already sitting there, switched on, unused. The product is what you build once you stop trying to own the parts.

You shipped it. Did it work?

Sat, 11 Jul 2026 00:00:00 GMT

Ask an engineering team what they shipped last quarter and you'll get a crisp answer: a changelog, a burndown, a wall of merged pull requests. Ask the same team what any of it did — whether users signed up faster, activated more, stayed longer, paid — and the room goes quiet. Somebody opens a dashboard. Somebody else says "hard to isolate." The honest answer, most of the time, is that nobody knows.

This is strange, when you say it out loud. We instrument everything up to the moment code lands. Tests, CI, code review, deploy tracking, error rates, latency graphs. Then the code reaches real users — the entire point of writing it — and the instrumentation stops. The feedback loop that runs so tightly through development quietly dies at the merge button.

Output is easy to measure. Outcome is the thing that matters.

The reason we drift here isn't laziness. It's that output is trivially countable and outcome is not. Pull requests merged, story points closed, deploys per day — these are right there, already logged, and they feel like progress. So they become the metrics, and a team can run for years on a scoreboard that measures effort while never once checking the result.

The trouble is that a company doesn't run on velocity. It runs on sign-ups, activation, revenue, retention — the numbers it would actually notice if they moved. A quarter can be enormously productive by the output scoreboard and completely flat by the one that pays rent. If you only watch the first, you can't tell the difference between shipping a lot and shipping things that worked. Those are not the same skill, and confusing them is how teams get very busy going nowhere.

Velocity measures how hard the team is rowing. It says nothing about whether the boat is pointed at the shore.

Every deploy is a hypothesis

Here's the reframe we keep coming back to: a deploy is not the end of a task, it's the start of an experiment. You believed that redesigned onboarding would lift activation. You believed the new pricing page would convert. You believed removing that step would cut drop-off. Each of those is a claim about the world, and the moment you ship, the world starts answering.

Almost nobody stays to hear the answer. The ticket is closed, the PR is merged, the team is three features down the road before the numbers even settle. So the belief that justified the work is never checked. You keep shipping on instinct, and instinct never gets corrected, because correction requires looking back at a specific change and asking what happened after it. That's the exact loop most tooling refuses to close.

What we built to close it

This is the gap code-results exists to fill. It's a simple, stubborn idea: take a deploy — a real, dated event, not a guess — and line it up against the handful of business metrics a company genuinely watches. Sign-ups, activation, revenue, retention. Every metric has a before and an after. code-results puts the deploy on that timeline and shows you what moved once your change reached production, read by the same team that shipped it.

The discipline is in what it refuses to do. A deploy and a metric moving at the same time is a correlation, not a proof, and we don't dress it up as one. Ship into a holiday spike and revenue climbs for reasons that have nothing to do with you; a genuinely great feature can land the week a competitor undercuts you and read as flat. code-results draws the line clearly and lets you read it like an adult — a strong signal you go investigate, not a gold star it hands out. Honest correlation you can act on beats fabricated causation every time. The goal isn't to declare victory. It's to make the question askable at all.

Why a tiny studio cares about this

We didn't come to this from theory. We came to it from operating our own products, which is the one rule this studio runs on: we only build what we run. Operating a product is where you learn that shipping and succeeding are different events, sometimes by weeks. We wanted the shape of that answer for our own work — did that change do anything? — and found that the tooling to see it barely existed.

So we built the thing we needed, the same way ganttchart.ai came out of wanting a plan in the ten minutes before a meeting. code-results is what it looks like to take the studio's oldest belief — a launch is the start of finding out if you were right — and turn it into something you can actually watch happen.

The scoreboard that counts what you shipped will always be easier to keep. It's also the one that lets you fool yourself. The harder scoreboard — did it work? — is the only one the business is actually keeping, whether you look at it or not. You may as well look.

Gantt chart, kanban board, or to-do list?

Sat, 04 Jul 2026 00:00:00 GMT

Somebody on your team just said "we need a plan," and now you're staring at three tabs: a Gantt chart tool, a kanban board, and a blank to-do list. They all promise clarity. They are not interchangeable. Pick the wrong shape and you'll spend the project fighting your own plan — updating a chart nobody reads, or missing a deadline that a chart would have made obvious in week one.

The good news: choosing is one question, not a personality quiz.

The only question that matters

Does your work have a deadline that other work has to line up against?

That's it. If yes — things must happen in a certain order, by a certain date, and some tasks can't start until others finish — your plan has a time dimension, and you want a timeline. If no — the work is a pool of items that get done as capacity frees up, and "when" matters less than "what's next" — your plan has a flow dimension, and a board or a list will serve you better.

Everything else (team size, tool budget, how much your manager likes colored rectangles) is detail.

What each shape is actually for

A to-do list is a memory. It answers one question: what needs doing? It's the right shape when the work is yours alone, the items are independent, and nothing is waiting on anything else. Groceries, bug triage, the fifteen small chores of a launch week. The moment one item can't start until another finishes, the list starts lying to you — it shows "write announcement" and "get legal sign-off" as equals when one of them is quietly blocking the other. A list has no way to say waiting.

A kanban board is a flow meter. It answers: what's moving, what's stuck, and what's next? Work enters on the left, gets pulled through columns, and exits done. It's the right shape for continuous work with no finish line — support queues, content pipelines, a team shipping improvements every week forever. Boards are honest about capacity ("why are nine cards In Progress?") and silent about dates. A board cannot show you that the whole thing needs to be done by March 28, because a board doesn't believe in March 28.

A Gantt chart is a promise made visible. It answers: will we make the date — and if not, which task is to blame? Bars on a calendar, arranged so dependencies are visible and the critical path stands out. It's the right shape when the project has a beginning, an end, a deadline someone said out loud, and tasks that wait on each other. Launches, events, migrations, renovations, anything with the word "by" in it.

The honest trade-offs

Every shape has a failure mode, and it's usually the reason people switch:

Lists scale down beautifully and up terribly. Twelve items, fine. Sixty items across four people with three deadlines — you've built a Gantt chart's worth of complexity with none of its visibility.
Boards hide deadlines until they're emergencies. "It's in progress" is a soothing answer right up until someone asks whether it'll be done by the launch date, and nobody can say, because the board was never asked to know.
Gantt charts rot when edits are expensive. A timeline is only as good as its last update. If moving one bar means an afternoon of dragging cells around, the chart freezes into fiction and the real plan retreats into hallway conversations. (This is a tooling problem, not a Gantt problem — more on that below.)

Mixing shapes without making a mess

Real projects usually deserve two shapes at two altitudes. The pattern that works: a timeline for the room, a board or list for the desk. The Gantt chart holds the phases, milestones, and dependencies — the five-to-twelve bars everyone points at in the Monday meeting. The kanban board or to-do list holds the forty tickets inside the "Build" bar — the detail only the builders need. The chart answers "will we make the date"; the board answers "what do I pick up next." Trouble starts only when one tool is asked to answer both questions at once.

If you landed on "Gantt chart"

The traditional objection is that timelines are expensive to make and worse to maintain — true for spreadsheets, true for heavyweight PM suites, and the reason half the plans that should be charts live in someone's head instead. It's also the specific gap ganttchart.ai was built for: describe the plan in plain English — the same sentence you'd say in the meeting — and get back a real chart with tasks, durations, dependencies, and milestones, editable by dragging and shareable as a link, no accounts needed on either end. The ten-minute version of that process, including the paragraph-writing trick that makes the chart draw itself, is in our step-by-step guide, five finished charts with their prompts are in the worked examples, and the story of why we built the tool at all is in the case study.

And if you landed on "board" or "list" — genuinely, use the board or the list. A timeline you don't need is just a prettier way to be behind schedule. The best shape for a plan is the one your team still believes in three weeks after you drew it.

How to turn a plain-English plan into a Gantt chart

Sat, 04 Jul 2026 00:00:00 GMT

Every project plan starts the same way: as a few sentences. "We're launching the new site in six weeks — design first, then build, content can overlap with build, and we need a week of QA before go-live." That's a real plan. It has phases, an order, a deadline. What it doesn't have is a shape anyone can point at in a meeting.

A Gantt chart is that shape — bars on a calendar, one per task, arranged so you can see what happens when and what's waiting on what. Getting from the sentences to the chart is the part most people dread, and it's why so many plans stay trapped in someone's head. It doesn't have to be painful. Here's the whole process, whichever tool you end up using. (Not sure a timeline is even the right shape for your plan? Start here — it's one question.)

The four things every timeline needs

However you make the chart, it's built from the same four ingredients. If your plain-English description contains them, the chart almost draws itself:

Tasks — the chunks of work, named the way your team actually talks about them. "Design," "Build," "Taste-testing photos." Five to twelve is the sweet spot; past twenty you're writing a to-do list, not a timeline.
Durations — how long each chunk takes. Rough is fine. "About two weeks" beats a falsely precise "11.5 days" that nobody believes anyway.
Dependencies — what can't start until something else finishes. This is the ingredient people skip, and it's the one that makes a chart worth reading. "Build starts when design is done. Photos can happen during build."
Milestones — the moments that matter to people outside the work: the launch, the review, the handoff. A milestone is a diamond on the chart and a date in an email.

Notice that all four fit comfortably in spoken English. You already say things like this out loud. The whole trick of planning is writing down what you'd say. (And when someone in the room reaches for the certified vocabulary — critical path, slack, finish-to-start — the plain-English glossary translates.)

Write the paragraph first

Before you open any tool, write your plan as one short paragraph. Not bullet points — a paragraph, with the ordering words left in: first, then, while, once, by.

First two weeks: design. Then three weeks of build — content writing can overlap with the second half of build. Once build and content are both done, one week of QA. Launch by March 28.

Those ordering words are your dependencies. "Then" is a finish-to-start link. "While" and "overlap" are parallel tracks. "Once X and Y are done" is a merge. "By March 28" is a milestone with a deadline. A paragraph like this is a complete project plan in about fifty words — everything after this step is just rendering.

Three ways to render it

The spreadsheet way. List tasks down column A, dates across row 1, and fill cells to make bars. It works, and everyone's done it once. The problem shows up on Tuesday when the design phase slips two days and you're re-coloring forty cells by hand. Spreadsheets store the picture of a plan, not the plan — they don't know your bars are connected. (If the spreadsheet is where your team lives anyway, we wrote the honest guide to Gantt charts in Google Sheets — three methods, exact formulas, and the limits.)

The project-management-suite way. Heavyweight PM tools make excellent Gantt charts and will happily manage resources, budgets, and burndown too. If you run a twenty-person program, that's your answer. If you need a timeline for a six-week project, you'll spend more time setting up the tool than doing the plan — and everyone you share it with needs an account and a tutorial.

The plain-English way. This is the gap ganttchart.ai exists to fill: paste in the paragraph you wrote above and it comes back as a real chart — tasks, durations, dependencies, and milestones on a proper timeline, in seconds. The AI writes the first draft; you stay the editor. Drag what it got wrong, rename what it guessed at, and share the result as a link with no accounts on either end. We built it because we kept writing that paragraph and resenting every tool that made us re-type it as form fields. (The full story is in the case study.)

The mistakes that sink timelines

We've drawn a lot of these charts, for our own projects and everyone else's. The failures are predictable:

No dependencies. A chart where every bar starts on day one isn't a plan, it's a wish. If nothing on your chart is waiting on anything else, you haven't finished thinking.
Too many tasks. The chart is for the room, not the worker. "Design" is one bar even if it's forty tickets. Detail lives in your issue tracker; the timeline earns its keep by being readable at a glance.
No slack. If the plan only works when nothing slips, the plan doesn't work. Give the bars room to breathe — or at least put the milestone a week after the last bar ends and don't tell anyone why.
Treating the first draft as final. A timeline is a conversation starter. The moment it meets reality it will be wrong somewhere; the question is whether your tooling makes the correction cost thirty seconds or thirty minutes. Cheap edits are the difference between a chart people update and a chart people quietly stop believing.

Ten minutes, start to finish

That's genuinely the budget. Write the paragraph (three minutes — you already know the plan). Render it (seconds, if the tool meets you where the plan already is). Adjust the two bars the first draft got wrong (two minutes). Share the link. You still have five minutes before the meeting — which, not coincidentally, is exactly the moment we designed for.

If you'd rather start from a finished chart than a blank page, we keep five worked Gantt chart examples — a website launch, a product launch, an app MVP, a house move, and a meetup — each with the exact prompt that generates it.

In defense of small software

Sat, 04 Jul 2026 00:00:00 GMT

Somewhere along the way, software got ambitious on our behalf. You go looking for a way to make a timeline and come back with a "work operating system." You want to read the news and end up with an app that wants to be your homepage, your inbox, and your social network. Every tool is a land grab now; every product wants to be the place where you live.

We think there's an honest alternative, and it's the reason this studio exists: software that is deliberately, proudly small.

Small is a feature

Small software does one job. Because it does one job, you can learn it in a minute, trust it completely, and forget about it the moment the job is done. That last part matters more than the industry likes to admit — the best tools are the ones you spend the least time in, not the most.

Big software can't afford to think this way. When a product's success is measured in daily active minutes, "get in, get out" is a bug, not a feature. So the tour gets longer, the notifications get chattier, and the one thing you came for gets buried under twelve things you didn't.

A tool should be judged by how quickly it lets you leave with what you came for.

What small looks like in practice

Our two products are both answers to the same question: what's the least software that completely solves this?

ganttchart.ai exists because making a timeline shouldn't require learning a project-management suite. You describe the project in plain English; you get a chart you can edit and share. There's no workspace to configure, no team to onboard, no methodology to adopt. The whole product fits in the gap between "I need a plan" and "here's the plan."

DReader exists because reading headlines shouldn't cost you a gauntlet of ads and layout shift. It's a reader. It shows you the headlines, readably, fast. That's the entire pitch, and we consider the shortness of the pitch a point of pride.

The economics of staying small

Here's the part that makes it work: we're a tiny studio with no outside investors. Nobody needs us to triple engagement or invent a platform story. A product that quietly does its job for the people who need it is, for us, a complete success — not a stepping stone to some larger ambition.

That freedom cuts the other way too. Because we run everything we ship, every feature we add is a feature we're on the hook for at 3 a.m. Small isn't just a design philosophy; it's how a small crew keeps its promises. Scope we don't add is scope that can't break.

An old idea, honestly

None of this is new. "Do one thing well" is older than most of the software industry. We're just applying it in an era that has largely talked itself out of it — and finding, again and again, that when you hand someone a tool that respects their time, does its job, and asks for nothing else, they notice.

Small, useful software, built through the night. It's not a compromise. It's the point.

The fastest page is the one that's already there

Sat, 04 Jul 2026 00:00:00 GMT

We preach small software, so it was awkward to notice that our own homepage had quietly become the opposite. The page looked light — a headline, two product cards, some cartoon trolls — but under the hood it was shipping 312KB of JavaScript, and the very first thing that JavaScript did was reveal the page. Until it loaded, parsed, and ran, the headline sat in the HTML at opacity: 0. Twenty-three elements, including the biggest one on the screen, invisible by default.

Turn off JavaScript and our homepage was a beige void with a navigation bar. On a slow connection it was that same void, just temporarily. We had built a fast static site and then hidden it behind the slowest thing on the page.

How sites end up like this

Nobody decides to hide their headline. It happens one reasonable choice at a time. You want a little polish, so you reach for an animation library. The library animates things in, which means everything starts out — opacity zero, twenty pixels low. The animation runs in JavaScript, so the starting state ships in the HTML and the finished state only exists after hydration. Each section copies the pattern from the last one. Every individual step made sense; the sum was a page that didn't exist until the framework said so.

The cost isn't hypothetical. The headline is the page's largest paint, the thing performance tools measure everything by. Search crawlers that don't run scripts saw the void. Readers on hotel Wi-Fi saw it too, for seconds at a time. And all of it bought us nothing — the finished page looked identical to one that could have just… been there.

The rebuild: same motion, no dependency

So we rebuilt the homepage with one rule: the finished page is the default, and motion is a courtesy on top. Everything else followed from that.

The hero's staggered entrance is now pure CSS — a keyframe and four animation delays. The scroll reveals further down the page are driven by about twenty lines of inline script and an IntersectionObserver. Crucially, the "hidden" starting states only apply when a tiny inline script has flagged that JavaScript is actually running. No script, no hiding: crawlers, readers with scripts disabled, and anyone who prefers reduced motion get the complete page in the raw HTML. The little Gantt chart still draws its bars when it scrolls into view; the trolls still wiggle when you poke them. The contact form is a plain HTML form that posts without JavaScript and gets politely upgraded when it's available.

Client-side JavaScript on the homepage after the rebuild: zero bytes. Not "less." Zero. The animation library, the UI framework, the hydration step — all of it turned out to be scaffolding we could take down once we asked what the page actually needed.

What we gave up

Honestly? Almost nothing. The one real trade is that the CSS animations are simpler than the physics-based ones the library offered — an ease-out curve instead of a spring. We looked at the two side by side and couldn't defend the difference costing what it cost. If a future feature genuinely needs client-side state, we'll pay for JavaScript where it earns its keep, on that feature, and nowhere else.

Why a two-product studio bothers

This is the same argument we make in defense of small software, pointed at ourselves. A tool should be judged by how quickly it lets you leave with what you came for — and for a studio homepage, what you came for is to find out what we make and whether we're any good. Every kilobyte between you and that answer is scope we added for us, not for you.

The fastest page isn't the one with the cleverest loading strategy. It's the one that's already there when you arrive.

The ten minutes before the meeting

Fri, 26 Jun 2026 00:00:00 GMT

Every product has a moment it's really for. Not a persona, not a market segment — a moment. A specific point in someone's day when they reach for your tool because something needs to happen right now.

For ganttchart.ai, that moment is the ten minutes before a meeting. You're about to walk into a room (or a call) and someone is going to ask, "so what's the plan?" You have the plan — it's in your head, in plain English, maybe in a few bullet points. What you don't have is the picture. And the meeting starts at half past.

Once we named that moment, every design decision got easier. Here's what designing for ten minutes actually did to the product.

It set the input

With ten minutes on the clock, nobody is going to fill in a form with start dates, durations, and dependency dropdowns. The only input fast enough is the one you already have: the sentence in your head. So the input is a sentence. "Launch the bakery website in six weeks: design, build, taste-testing photos, then go live." That's a complete, valid project description.

It killed the account wall

Sign-up flows are where ten-minute tasks go to die. Verify your email, pick a workspace name, invite your team — the meeting is over before the onboarding is. So the chart comes first. You should be looking at a usable timeline before most tools would have finished asking who referred you.

It decided what "done" means

A tool for the ten-minute moment doesn't need to be where the project lives. It needs to produce a thing you can walk into the room with: a chart that looks credible on a shared screen and travels as a link. Editable, because the AI's first draft is a draft. Shareable by URL, because "let me email you the file" is another ten minutes you don't have.

It made drafts disposable

Here's the second-order effect we didn't fully anticipate: when a chart costs seconds instead of an afternoon, people stop treating plans as precious. They generate a version, hate it, say so out loud, and generate another. The plan improves because iterating is cheaper than defending. Slow tools make people commit to their first idea; fast tools let them argue with it.

The general lesson

"Who is this for?" is a good question. "When is this for?" turned out to be a better one — it's much harder to hand-wave. A moment has a clock on it, and the clock makes the trade-offs for you: what to build, what to cut, and what "fast enough" actually means.

Find the ten minutes your product is for, and design for the clock.

Why we only build what we run

Thu, 18 Jun 2026 00:00:00 GMT

trolls.dev has one rule that shapes everything else: we only build products we run ourselves. No client work, no agency projects, no "ship v1 and hand over the keys." If it has our name on it, we're the ones carrying the pager.

This sounds like a business-model choice. It's really a quality mechanism.

Handoffs hide the truth

When you build software for someone else, the project has a finish line: the handoff. And finish lines change behavior. Corners that won't be visible at delivery get cut. Edge cases become "known issues." The demo path gets polished while the paths real users take on a Tuesday get whatever time is left.

None of this requires bad intentions — it's just what happens when the people who build a thing will never have to live with it. The feedback loop is severed exactly where it matters most: after real users show up.

Operating is where the learning is

Running a product teaches you things no spec review ever will. Which features people actually touch. Which "quick" flows have a step everyone stumbles on. What breaks when a link gets shared somewhere unexpected. The emails from real users — we read every one — are worth more than any amount of upfront research, but you only get them if you stick around after launch.

A launch isn't the end of the project. It's the start of the part where you find out if you were right.

It forces honest scope

Knowing we'll operate whatever we ship is the best scope-control mechanism we've found. Every feature is a permanent commitment: something to monitor, patch, explain, and keep working for as long as the product lives. That math makes you ruthless about what earns its way in — and it's a big part of why our products stay small on purpose.

Long-haul software

The quiet crisis in consumer software is trust: tools get acquired, redesigned into ad platforms, or abandoned. The fix isn't a promise on a landing page — it's an incentive structure. Ours is simple: we're tiny, we're not chasing a flip, and our products are things we wanted for ourselves. DReader stays ad-free because we're its heaviest users. ganttchart.ai stays fast and simple because we make our own timelines with it.

Build only what you run, and you can't help but build things meant to last. It's a small rule. Like everything else around here, that's the point.