Shutting down Hyperlint - the post-mortem

I’m shutting down Hyperlint.

Here’s what happened and how I got here. It’s a post-mortem.

an analysis or discussion of an event held soon after it has occurred, especially in order to determine why it was a failure

The starting point

It all started with this thesis.

The internet creates opportunity for independent entrepreneurs to build small (but lifestyle meaningful) businesses.

Many companies will attempt to solve this general problem. In the market, there will be a focus on larger opportunities. That means people will eschew smaller opportunities. “Lifestyle profitable” businesses can be meaningful for an individual but the opposite for a VC.

Specifically my ‘ChatGPT’ moment was that I believed now was an exceptional time to start a niche business. I still believe that and the evidence of success is there, here’s one from just this past week.ys

Shlomo sold his 6-month-old, bootstrapped vibe-coding startup Base44 to Wix for $80 million, Wix announced Wednesday. And the deal was cash, Wix confirmed to TechCrunch.

Unfortunately, Hyperlint wasn’t that. Let’s discuss why.

The turning point to starting

In 2024, I was able to convert some key customers. I won’t repeat them in detail here but I was able to gain several key customers / design partners using cold outbound sales and networking.

That was a turning point for the idea because that gave me the inkling that there were more to follow shortly. I got past $10k ARR reasonably quickly and although the sales process wasn’t trivial, it was complete.

After rebuilding the product (or parts of it) several times (the perils of vibe coding), I finally got something that I was able to consistently run and that worked. Basically the first time I had built something 100% from scratch.

At this time, I also experimented with a co-founder who realized that he didn’t share the passion for the space and so was back solo after that little experiment.

product

The ‘final product’ was a GitHub Application that a user installed on their repository. This app leveraged GitHub app event infrastructure to monitor for pull requests that contained documentation changes and would review those changes according to the users (a) vale style guide or (b) plain text style guide.

It could also automate certain things for them.

For instance, we could crawl their site, find broken links and open up pull requests for them, we could also alert on changes in their OpenAPI specifications, telling them which files might need to be updated.

I also experimented with other automations, agent style interfaces, etc.

I’m closing things out with ~200 installations and over 10k repos monitored.

GTM

After getting something stable, towards the end of 2024, I realized that I need to get crispier on my go-to-market process.

I set goals this year for outbound, for targets, and for my approach. It was time to try and force more growth in the product.

The goal was simple, hit the sales goals (and start tracking towards them) or put everything back on the table.

Inbound sales was relatively meager at this point, it happened but the volume wasn’t there.

Headwinds

As I started my outbound sales, things started off quite well.

People would ‘answer the phone’ - I could get on calls no problem.

However, the sales process was slower. Security reviews (due to the nature of the GitHub application) elevated my customer acquisition cost and effort. Little tiny frictions came up repeatedly. I anticipated some of this, obviously, but not to the extent that I got it on the other end.

It just wasn’t happening. My successful sales benchmark drifted further from my actually executed sales.

I decided to call it. The lessons are the remainder of this article.

The post-mortem

The big problem was there wasn’t one big problem, it was lots of little problems. The biggest post mortem I had is that I probably should have stopped sooner. It may have gone on too long.

But I digress, let’s move into specific issues.

The buyer (or lack thereof)

my ICP was technical writers for technical products.

The first customers I got had clout internally and could get deals done. This, in some sense, led me astray because I thought it would repeat in more organizations.

Lack of budget

The first customers didn’t have budget, but they could sell internally reasonably easily to get it.

That was not repeatable. The next ones did not have budget or didn’t know how to advocate for it. They didn’t have dedicated budget and have to go to other people. You can get it done, but it was pretty common for me to talk to people seriously experienced in the technical writing domain that this was the first time they had been ‘cold’ DM’d.

Lack of tool culture

The bigger problem, for me, is that technical writers do not have a tool culture.

They’re not tinkerers.¹

The fact that Hyperlint could take their style guide and make it a rule set was interesting, but there were so many rule violations (I built infra to try and control this to little success), that people found the product too chatty. If I turned the ‘volume’ way down, they’d complain it wasn’t chatty enough and was missing issues.

These were all things that I experimented with exposing to users so that they could control them but again, because of lack of tool culture, they didn’t want to.

As I spoke to more and more users, this became more and more apparent.

Resistance to AI / automation

There is quite a bit of existential fear in the technical writing domain with respect to AI. I expected people to embrace this kind of tooling earlier on, as a means of freeing up their time for more important things.

But with the lack of tool culture, I didn’t observe successful adoption here.

Competitive dynamics

MCP servers

Earlier this year, MCP servers started popping up more regularly. I started working on some product developments around this and just realized that MCP servers could probably get you pretty far with respect to my product. It wouldn’t be perfect but it was close enough that I saw the writing on the wall, the standardized ‘protocol’ for reading and writing data via tools would mean that my product wouldn’t need to be in the hot path.

Code editing tools

On top of that the Cursors and the Windsurfs had really picked up momentum when it came to agentic coding. Those tools write markdown with little issue.

Model improvements

On top of that, the models were getting better and better. In some sense this helped me but if I couldn’t justify being in the “user’s daily flow” like a chatGPT and if I couldn’t build that good enough or fast enough, I didn’t have a reason to exist.

The thought experiment on pricing and value

Let’s say that I provide 100 units of value. If you can get to 80 units of the value with a general purpose tool, that last 20 units needs to be valuable to justify your existence. Otherwise, you’re going to lose in the marketplace.

You also need to be able to price effectively against those 20 units of value and you need to be able to deliver them with limited friction.

I couldn’t do that.

Onboarding

Onboarding was a pain.

It always tool several video calls to get to the installation.

My thinking was that because GitHub provided the ‘rails’ through their marketplace, it’d make this smooth (initial assumption). It didn’t because of the lack of buyer technical ability (for the most part). Basically the technical writing teams, even if they were using GitHub, had to escalate to IT to get an installation.

Onboarding typically involved navigating security protocols and multiple stakeholders, increasing customer acquisition costs.

Customizing Hyperlint for the users

On top of that, because of the whole tool culture, my customers didn’t always have the knowledge or ability to customize the style guide. It takes work because you’re basically optimizing a prompt and you need to run data through that pipeline to truly ‘optimize’ that prompt.

R&D issues

I’m not the best in the world at writing code. I am self-taught.

I just did the best that I could vibe coding this thing, but in the end it was a lot of lines of code (it’s all relative).

I did have to rebuild the product several times, or at least core components of it, and that slowed down execution.

UX Issues

Building agents as GitHub Apps was not ideal.

The experience I gave to customers was just too slow. Pull request reviews and comments involved a lot of tracking and a lot of debugging. was very annoying to maintain.

For instance, I had to index the comments that I posted so that I wouldn’t post duplicate comments. That meant figuring out what comments were actually created against the GitHub API. Doable, but annoying.

Vale is not great. It’s powerful but it’s flaky and I’ve spent many hours just mucking around with it. The rules engine isn’t great and is quite finicky.

Candidate pivots

So, after all of this and writing all of this up. I thought about what might be next, how could I repurpose what I had?

Different end user / product - why not target PMs or engineers?

I DQ’d this because it was a substantially different product and market. There were well funded competitors and while that doesn’t spell death knell, it did mean increased competition and need for improved execution.²

Again, I didn’t have a POV on how I could be better than those alternative tools.

Different delivery method - why not use open source or something?

this is a completely net new re-imagining of the product and at the end of the day it’s a text editor. That means I’d be competing with Cursor et al. Fun if you’re at a big company, not fun if you’re a bootstrapped indie hacker.

but, perseverance

It’s not unreasonable to think that success is just around the corner on this project. This is typically my default. Just power through!

I think Varun nails it, at least in my case.³

You don’t win an award for doing the same wrong thing for longer. It might feel better to tell your coworkers, investors, friends that you’re still doing the thing you did. But down the line when you fail none of them will care.

This just doesn’t have legs as it currently stands and it’s not the area that I want to spend the next 5 years of my life swimming against the tide.

At the end of the day, I’ve got to make a choice for how to spend my time. Is this a good use of my time, or not? I put that in my original thesis

The emphasis here is on (a) public commitment, (b) showing up in public, and (c) documenting learnings for others.

I built something from scratch as a solopreneur and sold it to some of the largest companies on the planet. There’s a lot of learning in that and I’m proud of it.

However, in doing so and trying to get things to the next level, I realized that it’s not my community. I’m not serving the people that I want to serve, and that continuing is just too costly for me. This actually hit harder than I originally anticipated, if I could have built a sustaining lifestyle business around this, I would have been satisfied. However, the fact that it was challenging and I couldn’t quite break into ‘lifestyle sustaining’ meant that I had to really love the users and community I was serving. That just wasn’t the case, technical writers are friends but they are not my community.

That doesn’t mean it’s ‘over’ (in the larger sense), there are still plenty of ideas bouncing around and opportunities in front of me but this one is now sunset.

Conclusion

If I had to run it back I think I could have learned more earlier and avoided some pain. I think that I could have more systematic in my original outbound and initial product iterations to question the actual product.

I misled myself with my initial customers, that they were early adopters not pure innovators.

The problem Hyperlint solves is 100% real. That’s painful for me as a builder because there’s a thread to pull on here.

This problem exists, people get it. I just don’t think it’s that (a) monetizable and (b) that easily distributed (in product distribution terms).

We all have so many things that we can spend our time on every single day and I realized this wasn’t my destiny to continue on this particular one.

Next Steps

At this point, I’m going to be open sourcing Hyperlint as a tool. I’m going to more or less Claude Code-it. Make it a command line interface to be able to use to edit your writing. You’ll have a configuration, you’ll edit that config, and you’ll be off to the races.

I could try and force some billing model out of it, but I’d rather just give the capability to the community and to my existing customers, that way they can continue to solve things with Hyperlint but I can wind down the support area that I have today.

I’ve already shipped one OSS component, smolcrawl and hope to add more soon.