Writing by Scott Clark

Making New Mistakes Faster as a Second-Time Founder

Tue, 28 Jul 2026 16:30:00 GMT

When I started Distributional in 2023 I thought I had it all figured out. I had sold my first company, SigOpt, to Intel in 2020 and had spent the previous 3 years as an executive learning from the inside of one of the most iconic tech companies of all time. I had built SigOpt from my PhD thesis in 2014 and ran it for 7 years before the acquisition. I made many, many mistakes along the way as I learned company building, management, and enterprise sales mostly by trial and error. After reflecting on a decade of mistakes and learnings I was ready to embark on a new adventure with all of my experience earned through blood, sweat, and tears.

I thought I was going to be able to accelerate through the first few stages of company building because I would be able to avoid old mistakes, repeat what worked, and make all new mistakes faster. What I didn't account for was that the entire market and world was fundamentally shifting, so many old lessons didn't apply directly. I also overfit to my previous successes, which turned them into mistakes, forcing us to pivot multiple times along the way.

I had to learn the hardest lesson again: startups are hard, there are no shortcuts to product-market fit, and you need to do it the hard way for it to have any chance of working. There is nothing like the free market to humble you, but the upside is that there is still so much to learn. Here is what I did right, wrong, and what I will do differently as I keep building.

What worked the first time

On paper, SigOpt was a great run. We went through Y Combinator in Winter 2015, raised from top investors like a16z and SV Angel, took the Bayesian optimization tooling I'd built in grad school and open sourced at Yelp and turned it into an enterprise product, grew the team, stood up a sales motion, and sold the company to Intel in 2020. Underneath those highlights was a first-time founder figuring it out as we went, often via trial and error. The thing that saved us over and over again was the incredible team and culture I was able to build with my co-founder.

But the big timing calls mostly worked: when we hired, when we scaled, when we leaned into go-to-market, when we sold. I took some of our luck and attributed it to skill, forgetting some of the misfires along the way. Hiring ahead of product-market fit had worked, because the ML-infrastructure market grew into the capacity we built. Standing up sales early had worked, because buyers were already forming budgets around our category. Eight years later, none of that felt like a playbook I was choosing to re-run. It felt like knowing what I was doing.

Success is a worse teacher than failure

Mistakes are often obvious immediately or at least in hindsight. You miss the quarter, you lose the deal, you watch a launch land flat, and the lesson arrives with a timestamp and a bruised ego. Failure hands you a signal to reinforcement learn from.

Success gives you almost no information about why it worked. Was it the play? The timing? The market regime? Luck? A single evaluation on one company outcome can't separate those variables. Even SigOpt's ending made the point: we were mid-raise, term sheets all but verbally agreed, when the news broke in a fundraising meeting with one of our current investors that the NBA had suspended its season due to COVID. The pandemic changed the world, the round evaporated, and we sold the company later that year. A good outcome by any startup standard, and the variable that timed it appears in nobody's playbook. A founding career is a training set with a few samples per company, and I fit a confident model to mine. Overfitting is roughly the first danger you learn to fear in getting a PhD, and I did it anyway, with my own resume as the training data.

It gets worse, because the environment isn't stationary. The AI market between 2015 and 2023 didn't drift, it monotonically grew, and by the end it was jumping several times a year: categories forming and dissolving in months, buyers rethinking budgets mid-cycle. My old plays weren't wrong in some universal sense; they were fit to a distribution that no longer existed. Success can often tilt your policy from exploration all the way toward exploitation. You've found high ground before, so you march straight at where it was. When the terrain moves, the value of exploration goes back up, and your own experience is the voice insisting you don't need it. And when building a startup the terrain is always moving, sometimes catastrophically.

What re-running the playbook looked like

I'll always remember what one of our board members said after we went through our first pivot and reduction in force: "Every great company needs to figure out product, sales, operations. But you need to do it sequentially and in that order."

The first few years of Distributional were about me trying to do it all at once. I wanted to skip past the parts I had already done and get to new ground as fast as possible. In doing so I starved the part that mattered the most: building something people actually want. By trying to scale up sales and operations I thought I was "spring loading" the business for the second we found product-market fit. But in reality I starved our ability to focus on product or iterate as fast as the changing market demanded.

I hired and scaled ahead of product-market fit, because last time that timing had been right. This mistake compounds quietly, step by step. You hire ahead of fit, and the new team needs a roadmap to build and sell. A roadmap demands conviction you don't actually have yet, so you commit to your best current guess. But the team also grows so big that you need to operationalize things that should be fluid. Once the org is executing on that process, changing it costs a reorg, so each piece of contrary evidence gets discounted a little. Momentum and process start being about the machine instead of the market. From inside, it looks like execution, but it really is starving innovation and speed. The result is all of the stress of a growing startup, with none of the results.

Naming the quadrant

We had vision-market fit more than once. Smart, senior people in our ideal customer profile agreed the problem was real and coming: AI systems need testing you can trust. People were excited to try the product when we were pitching. When we repositioned the product, the excitement was even greater. People agreed it was obvious and inevitable and we had a unique and valuable take on the problem. Every signal a founder wants to see, except the one that pays. Getting close is worse than not being close at all, because close is exactly the feeling that keeps you funding the push.

It took me too long to treat that pattern as a distinct false positive with a name, and that turned out to be the lesson.

Vision-market fit is resonance: people with real budgets and real problems agree that what you see coming is coming, and interest shows up wherever you push. The tell is what never happens next, if anything. The interest stays excitement instead of execution: nothing gets deployed because it wasn't a real pain. I remember in the early days of SigOpt, when we were selling hyperparameter optimization as a service to firms just learning about ML, we would sometimes get the response, "I can't wait until we have this problem, that will mean we have a system worth optimizing." In SigOpt we just had to go up market to find product-market fit, but with Distributional the whole field and concept we were pushing was so nascent that it meant there was no up market to chase, even the most advanced firms of the ML era were still figuring it out as they went.

Product-market fit is pull: buyers you didn't call show up, budgets form around your category without you in the room, and customers put you in their architecture diagram without being asked.

From inside any single good meeting, the two are indistinguishable. Vision-market fit is dangerous precisely because it looks like the opening scenes of product-market fit. The two are different, and scaling on top of the first one means scaling a hypothesis. The difference only shows up in what happens when you stop pushing, which is exactly the experiment a scaling company never runs.

The map I was actually on, drawn with axes I could only name later. Vision-market fit is the top-left quadrant: resonance keeps climbing, the pull line never gets crossed, and the quadrant keeps you alive exactly long enough to matter. Rooms lean in, rounds come together, pilots start, and none of it compounds on its own.

Naming the problem is what makes it escapable. An unnamed false positive just feels like early traction running a little late. A named one is checkable: you can ask, every quarter, what moved this quarter that we didn't push, and write the answer down.

In our case, the answer had been on the page for a while: the doubts that eventually proved decisive were sitting in the margins of our own strategy decks, in our own words, well before I acted on them. Strategy documents archive your disconfirming evidence whether you mean them to or not. And there's an irony worth saying plainly: I spent those years building software to catch the gap between how people assumed their AI systems behaved and how they actually behaved, but people were still figuring out these systems or just YOLOing them into production. The assumption I tested least was the one my own company was standing on: whether people had enough data, risk, and cared enough to actually test rigorously. I still believe the AI-testing market will mature the way I believed it would, but it wasn't maturing on the clock we were running.

Naming the trap also names the way out. The honest process is what you run when the answer keeps coming back "nothing pulled": you test the company against the real market instead of against your own hopes, with real conversations, serious diligence, and real alternatives on the table. You run it not because you've already decided to sell or to stop, but because a choice made against real alternatives is a decision, and a choice made against imagined ones is a story you tell yourself.

The accounting

So here's the honest version, without spin in either direction. Distributional did real work on a real problem, with a fantastic team and investors I'm grateful for, and the plays I imported didn't convert vision into product-market fit. The job of the CEO is to make the business successful and I was burning cash without making enough progress.

I can date the moment the pattern finally clicked into place for me. We were at an onsite with the team and had just had the best sales call in the company's history. They were basically pitching us the whole time, they had our problem, they were looking for our solution, they wanted to pilot as fast as possible. They shared our vision for the future. But when I got back to my room I started doing the math. If this deal went perfectly, if we hit every milestone and didn't catch any enterprise sales drag, then we could convert the pilot in 6 months and lock in our quoted rate. But I knew from SigOpt that there were dozens of things that would need to go right for that to happen, and we would need a dozen deals just like it to hit the numbers we needed, and every other deal in the pipeline was worse than this one. Even if we did great, it wasn't going to be good enough. If the best isn't good enough, you need to play a completely different game.

This led to our first reduction in force and pivot, after 2 years of hard sprinting. Then a similar thing happened again after we pivoted from pre-production testing to post-production analytics. (Read the pivot story here.) So I tried to run a process to find the company a home. We ran the process instead of arguing with it, all the way to the end: term sheets on the table, an offer for the whole team. At the end of the day, that's what made what came next an intentional decision instead of a drift.

We chose a hard pivot over both real alternatives: the exit on the table and the slow burn into nothing. We cleaned it up as well as we could: commitments honored, most of the team landing well together via one of the acquihire offers, and the company coming out the other side pointed at something I believe in even more.

That something is Talaria Scientific, still under the Distributional banner, just a new brand and hard pivot. The short version of the mission: A multi-agent harness for computational science, helping computational scientists research faster, better, and cheaper with AI.

New mistakes, on purpose

What I'm doing differently this time around is not "avoiding mistakes." The goal isn't fewer mistakes; it's newer ones, made faster, against current evidence instead of old wins.

Staying lean: Talaria Scientific today is a team of one plus contractors. Not because scale is bad, but because scale buys speed at the price of rigidity, and rigidity is what slowed my updating last time. Headcount converts hypotheses into commitments. I want my hypotheses cheap to kill for as long as possible, just like I did when building open source from my PhD before starting SigOpt.

Being my own customer: this time the ideal user is me. I spend my days running computational research on PDE neural operators and Bayesian optimization through the product I'm building, and when it's slow or wrong I feel it the same afternoon. The feedback loop went from quarters to hours, which means my gradient information finally comes from the present instead of from 2016.

Sequencing truth before scale: vision-market fit opens doors, and I'm glad for every one, but it isn't the signal to hire against. Product truth first, then pull, then scale, in that order, with the order enforced by keeping the company too small to fake it.

That being said, the answer isn't to invert every play that worked before. Inverting still lets the old data drive: overfitting with a minus sign in front. Some SigOpt lessons transfer just fine. The discipline is holding the old playbook as a prior instead of gospel, weighting it by how much the world has moved, and letting present evidence make the calls. In a market moving this fast, the honest weight on eight-year-old experience is smaller than feels fair.

There's a bigger question underneath all of this, about when to keep climbing the mountain you're on and when to change mountains entirely. Careers have many paths up many mountains, and that idea gets its own post.

For now, the all-new mistakes are underway. I can't tell you which ones they are yet, which is the point: if I could name them, they'd be the old kind. The new map is mostly blank, but one quadrant on it is already named. In a few years Talaria Scientific will have its own list of what worked, and I'm sure I'll look back with all new lessons learned.

Building this blog: Part II

Tue, 28 Jul 2026 16:00:00 GMT

Twelve years ago I published a post on this domain called "Building this blog: Part I". There was never a Part II. This is Part II, twelve years late, and the reason it finally exists is also the reason it might be worth your time: agents changed the economics of owning your own corner of the web, right as owning one started to matter again.

When someone wants to know who you are now, they often don't search; they ask an AI, whether that is a web chat app or Claude Code. A conference organizer asks a model whether you'd make a good speaker. An investor asks for a brief before a call. A hiring manager asks what you've actually shipped. The answer comes back assembled by an agent reading the public web on their behalf, and for that reader the front page isn't a search results page. It's whatever the agent can find, parse, and trust.

I want those answers shaped by what I've actually written (ie by my own record rather than by whichever fragments of it leak through other people's platforms). Writing that lives only inside a walled garden is at the platform's mercy twice over: the feed decides which humans see it, and the crawler policy decides whether agents see it at all. Ask a model about someone whose whole record sits behind those walls and you get an answer stitched from press mentions and stale bios, an answer about them that they don't own.

The alternative has a name in the same spirit as SEO. People are starting to call it AIO: optimizing your presence for the AI systems that read the web on people's behalf. It feels like early SEO, and the mechanics are simple: a canonical site you control, a markdown twin of every page so an agent gets clean full text instead of your layout, structured data so the answer engine doesn't have to guess, and a robots.txt that says yes. Whatever the discipline ends up being called (the SEO crowd already says GEO and AEO), the mechanical version is a few hours of work, and the agents people actually send already fetch it.

Engineers have been told to own their own site for twenty years. Most of us never finish. I know because I'm most of us.

Why this used to be a tax

In 2014, while I was at Yelp, I built scottclark.io from scratch on Pyramid, because Yelp was standardizing on Pyramid and I wanted to learn it. I deployed it to DigitalOcean. I wrote exactly two posts. The second one was titled "Building this blog: Part I."

What killed it was the maintenance tax. Every post required a context switch from research into web infrastructure: dependency upgrades, design, theme fights, deploy scripts. The site was supposed to be a writing surface and became a side project that ate the writing time. It was the woodshop problem: the first project in a new shop is always a workbench, and some of us sand the workbench for years and never build the furniture (and I tend to fall victim to yak shaving, bike shedding, and all the colloquial variants of this). My workbench had a comment system, but it only had two posts.

So the site went dark, and the pattern held for a decade. My resume repo tells the same story in commit history: steady updates through 2016, then nine and a half years of nothing public.

The unlock, and the new tax

What changed isn't that web frameworks got easier. The frameworks have been good for years. What changed is that the scaffolding tax became an agent's problem: the dependency upgrades, the build pipeline, the infrastructure, the long tail of small decisions that used to stand between "I should write this down" and a live page. This was the same realization that led me to start Talaria Scientific to accelerate computational science research.

Agents don't get you off the hook, though. They are very good at rapid prototyping, and there is still a lot of art and craft in making the prototype into the thing it was prototyping. Point an agent at "build me a personal site" and you get a generic landing page with rotating gradient blobs. What you actually owe the project is judgment (or what many people are calling taste): which tools do which jobs, what the contracts between them say, what stays open and what stays private, which way a fact propagates when it changes. The tax moved up a level, from scaffolding to composition, and composition is a much better use of the human.

Three repos came out of that judgment for me.

content_finder is a small, still-pre-v0.1 Claude Code-driven crawler that walks the public web for a person, verifies what it finds against stable identifiers, and produces a dossier on yourself: markdown files with citations and raw captures of every primary source it can find on the internet. I ran it on myself first. The output is the closest I have to a verified record of my public existence: twelve years of articles, every podcast and talk transcript I could recover, patents, papers, and press, each with the raw artifact saved so nothing has to be re-derived.

resume is my old LaTeX resume repo, modernized in a single April session after its long sleep. It now carries a markdown twin that is the source of truth for bio facts, a PDF build, and an AGENTS.md that defines the propagation order when a fact changes: dossier, then resume, then site, never the other direction.

scottclarkio is the published surface as a repo: an Astro static site behind S3 and CloudFront, provisioned by Terraform, deployed by a GitHub Action on every push. It reads facts from the other two repos. And it ships the full agent-facing surface: a JSON-LD entity graph on every page, a markdown twin of every page and post, an llms.txt and a concatenated llms-full.txt, a full-content RSS feed, and a robots.txt that explicitly welcomes AI crawlers by name, with a Content-Signal line that says yes to search, yes to AI input, yes to training. Building in the open means being fine with getting baked into the models, and getting baked in is the goal, not a concession: whether a model learns about me at training time or looks me up at answer time, the record it finds should be the one I wrote.

A site written for two readers. The dossier repo holds verified public facts, the resume repo holds bio truth, and the site composes both into two surfaces: HTML for the person, and a machine-readable stack (markdown twins, an entity graph, llms.txt, a full-content feed) for the agent they sent. The connective tissue between repos is markdown contracts. Facts flow one direction.

The composition lesson is in the boundaries. Each repo does one job, none of them tries to be a CMS, and the connective tissue is markdown: CLAUDE.md and AGENTS.md files that tell the next agent session what's true, what to read first, and what not to touch. When a fact about me changes, I know exactly which repo to edit, and the rest follow. There is no client-side JavaScript on the site; the only script tags carry JSON-LD data. There's no analytics tracker either, just the CDN's own logs: watching a live dashboard is fun, and fun isn't signal; I don't need to peek at an experiment on a minute-by-minute basis.

What I didn't build

The list of what I didn't build matters more than it used to, because the old constraint no longer enforces it.

I built content_finder because the artifact didn't exist: there was no off-the-shelf way to produce a verified, citable corpus of my own public footprint, so the only path to the dossier was the tool. Halfway through drafting a post, I also started designing a markdown collaborative-editing tool in my head, because pair-editing prose with an agent in a terminal has real friction. Then I caught myself: editors exist, and the artifact I was trying to ship was the post.

When the marginal cost of building a tool approaches zero, "can I build it" stops being the question, and "should I build it for this artifact, in this moment" is the question that remains. That's an explore/exploit tradeoff at the tool layer, the same one I spent years on in Bayesian optimization at SigOpt. Exploit, ie use what exists, is still the right default for almost everything, but the reason changed: it used to be that building (exploration) was too expensive, and now it's that your judgment is the scarce input and the backlog of artifacts is long. I built content_finder because I needed the dossier. I didn't build the editor because I just needed the post and Google Docs does just fine.

It compounded

The site turned out to be the trailhead, not the destination. This July, the same composition pattern shipped two more sites in one night: a company site with its own blog for Talaria Scientific, the company I'm building now, and a rebuilt distributional.com that restored years of the old company's technical archive at the original URLs. Every post on all three ships with the same agent-facing surface this site has. The same night, this site got the blog section you're reading, which is how a post titled Part II finally acquired a place to exist.

The build discipline scaled with it. Before these posts go live, the diffs are reviewed by frontier models from five different labs (Anthropic, OpenAI, xAI, Moonshot, and Thinking Machines), and the union of their findings, most found by only one of them, becomes the fix list. How that review loop works is a post of its own; the short version is that agents wrote the estate, different agents attacked it, and I adjudicated.

The speed

The receipts are what still surprise me.

The resume repo is the cleanest one: regular commits through October 2016, then silence, then a single commit in April 2026 titled "Modernize resume; align CV/md; add AGENTS.md and fork guide" that did more than the previous five years combined. When the company pivoted to Talaria Scientific, the resume, the CV, the PDF, and the site all updated the same afternoon, because a fact now has one home and agents carry it everywhere else.

This site went from first commit to live behind CloudFront in about ten weeks of part-time sessions, including the AWS infrastructure, the DNS migration, and the whole agent-facing surface. The AIO endpoints are the part I would never have gotten to alone; JSON-LD schema authoring is exactly the kind of yak-shaving that kills a research week, and it's exactly what an agent eats without complaint. On a normal weekday I have a handful of agent sessions open, and the one working on this site is rarely the one I'm watching.

At the end of the day, the work I did is the work that was supposed to be there all along: every design decision, every fact, every editorial call, every judgment about what not to build. What the agents ate was the tax that used to stop the project before that work could start.

In 2014 I wrote "Building this blog: Part I" and then went quiet for twelve years. This is Part II. It didn't feel 10x faster to make; it felt 100x faster, and somewhere in that gap is escape velocity: the difference between a backlog item that survives another decade and the post you're reading right now. Part III should take less than twelve years. If you've got a workbench of your own gathering dust, it might not need another decade for you to own your slice of the web too.