It's been six months since my cofounder and I broke up, and I figured it's time to publish an update on what I've been up to. To recap, David and I spent about a year exploring the startup idea maze in 2020, and while we were ultimately unsuccessful, we parted amicably. He's gone on to start a carbon accounting software company with a new cofounder who works in the oil&gas industry. I, on the other hand, have veered off the venture-backed startup route, and have been building a technical content agency, Frindle. This post is my attempt to share what I've learned in the process.
After the cofounder breakup, I decided to spend the summer pursuing some journalism projects and figuring out what I wanted to do next. I felt, for the first time, a real sense of freedom in my career, a desire to roam. This was completely disconnected from my material reality — it's not like I had a big exit or made a lot of money in crypto — but the startup failure was surprisingly liberating. I'd failed, the world hadn't ended, I hadn't collapsed emotionally, and I still wanted to try again, this time with a better set of parameters.
So I had a giant whiteboard in my living room, and I put all the possibilities on the board. This included everything from becoming a Junior VC to taking a full time developer job to writing a novel. Over time the options winnowed. Some things ended up not working out. Others I tried, and didn't like them as much as I thought I would.
One of the ideas on my board was a technical content agency. Because of my journalism background, my entrepreneur friends often asked me whether I knew any writers open to doing content writing for their startups. (I even curated a list of available content writers.) As a developer myself, I'd benefitted enormously from technical content in particular, although in the past I'd given little thought to how it was produced. For me, people who answered StackOverflow questions or wrote up long, free guides on SSL did so for inscrutable reasons, like kidney donors.
Still, I knew enough about software development to know that the average programmer wasn't leet-coding Dijkstra's all the time — they were copying code from blog posts, tutorials, documentation, running it, and praying that it worked. As the ranks of programmers swelled, software purchasing power moved into developer hands, and education and marketing converged, I believed that the market for high-quality technical content would only grow. I was also aware that I had exactly the right background for this.
Generally, in launching a business, it's not sufficient to talk about it, but that's exactly what happened with Frindle — I just started talking about it to everyone I knew and everyone I was meeting in the tech community, and it became very clear, very quickly, that there was a lot of demand. Multiple VC's who were trying to recruit me to be an investor, upon hearing that one of my other options was starting Frindle, ended up introducing portfolio companies as clients. Friends I'd long ago fell out of touch with, got back in touch to send me their friends' companies. Like engineers, it seemed that technical content was something every dev tools, platform, and API company wanted, but unlike the freelance developer market, which is crowded with players like Toptal and Moonlight, there was very little aggregated supply. To date, the only competitor I've really been able to identify for Frindle is draft.dev.
The demand meant that I was able to be choosy about what work Frindle took on. A number of early clients were in the Data Infra/Cloud/DevOps space and I decided to focus the agency around those verticals. This made it easier to accumulate domain expertise and share learning between clients. It also at least nominally matched my existing background, because I'd worked in infra at Uber and Google, although the truth is that a lot of the topics we create content on, I've had to learn on the fly. For example, the way you managed a distributed system in 2015 was with a bunch of bash scripts. Now there's Kubernetes and Terraform and GitOps. At Uber in 2015, we still used Vertica and Hadoop. Now everyone is on data warehouses like Snowflake and new-age ETL tools like DBT.
Some other tactical decisions I made included the decision to service only technical content (i.e. content that had code in it or required technical know-how). This took advantage of my comparative advantages, and made it easier to justify the high prices. Finally, while I started out with bespoke projects, over time I crystallized the services we offered into the following "packages":
- consuming, testing, and updating clients' external-facing documentation
- writing technical blog posts/tutorials/how-to's
- creating explainer and demo videos
In the beginning, it was just me fulfilling the work. But as the business grew, I brought on several contractors to help part-time with writing, video editing, and operations. I've never really managed people before and it still amazes me when I delegate and something actually gets done.
People management, of course, has brought its own set of challenges, but encountering these challenges, and overcoming them, somehow feels good, like muscle soreness after working out, rather than the existential angst of not knowing what to work on, which always felt bad.
Challenges
- Finding Qualified Writers
- Standardizing Pricing
- Operational Overhead
- Being Part of the Team
- Client Management It's only now that I'm in a client-facing business that I realize how spoiled I was working infrastructure, where there were basically no deadlines, and no external customers. Some things I still struggle with include:
- What to do if your client wants X but you actually think the right course of action is Y. Should you stand your ground or give your clients what you want?
One of my biggest worries was whether I would be able to find enough qualified contractors to fulfill work as I grew my business. I knew the cheaper option was to take writers and try to teach them about programming. The more expensive option was to take developers and teach them how to write. Initially, I went with the first option.
I ran a two-week course up-skilling nontechnical writers into technical writers. My hypothesis was that it was possible to teach trained journalists how to build a Flask webserver in two weeks. This turned out to be...incorrect. It'd been so long since I learned how to code that I think I just forgot how much knowledge is assumed...even things like using the terminal, or what a "string" is.
Eventually, I discovered that it was easier to go in the other direction, by tapping into non traditional pools of talent like graduate students in computer science and new moms and developers on “sabbatical”. What I could offer these people were two things: flexibility and public bylines. And I paid better than some competing tech writing programs that companies have set up. (Usually something like $700/blog post.)
I had trouble figuring out the best way to do pricing. Should it be per project, per hour, per monthly retainer? At this point, I largely try to do per project, but it's still a bit of a hodge-podge.
Maybe this is because I'm still early on, but many of my contracts are relatively short durations and they're frequently being renewed. This creates a lot of operational overhead, in terms of renegotiating, drawing up contracts, sending invoices, etc.
My clients will often plug me into their Slacks, which is great because it feels like you're part of the team, but then what are the expectations in terms of availability, attending weekly meetings, etc?
Incidentally, running Frindle has convinced me, more than ever, that the best startup ideas come from pain points you experience yourself. When we were full time ideating, I always felt like there was a dearth of problems, or at least a dearth of problems that other millennial tech founders hadn't already thought of. But now that I'm doing on the hands-on content creation work every day, I encounter problems all the time. Documentation software like Gitbook or Readme is clunky and visually unimpressive. It's hard to self-host a Ghost instance and keep it up to date. I have a contractor who is living in Taiwan but is a US Citizen — do I still need to get her W-9? Some of these problems already have software solutions. Others do not. If I were to ever build another software business, the following would be at the top of my list:
- Truly modern docs tooling
- Companies like Stripe and Twilio that are well known for their docs have entire engineering teams devoted to building docs tooling. If you can't afford to do that, your off-the-shelf options are basically Gitbook, ReadMe, or Docsaurus. None of these are, IMO, really great products.
- I recently learned about a new templating language called MDX that allows you to embed React components in Markdown. I would love a docs tool that is MDX on the frontend, headless Ghost on the backend
- For a lot of developer-facing projects these days most of the action is actually happening in Discords/Slacks. That's where a lot of questions get answered. There should be a way to automatically parse all the questions that are posed/answered in chat communities and lift them into proper documentation threads that can be indexed by Google.
- None of the have good analytics for what works and what doesn't
- Better Managed Ghost
- I've spent a lot of time working with Ghost sites. I like the product and respect the team. The core product is open-source, the managed service is a non-profit, and in a world where $10 billion is the new $1 billion, it takes a huge amount of integrity to not run after that.
- That being said, I think the existing managed ghost service, Ghost Pro, lacks customizability. In order to change the email templates or translate the transactional emails, you have to edit the core files (which are not accessible in the managed service), and self-host. I think there's room in the market for a better managed Ghost service, or even a build tool that does some of the upgrades/config stuff for you. Mostly, I'm bullish on the Ghost ecosystem. If you think of the number of sites online right now that are hosted on Wordpress, and if you think of Ghost as the new Wordpress, that's probably a half trillion dollar market.
Next Steps For Frindle
One of the qualms that a lot of tech people have about agency businesses is the lack of scaleability. Unlike software businesses, with zero marginal cost, every time I bring on an additional client, I have to pay an additional writer to service them. And unlike software businesses, I have to continually work to get paid. I can't just spin up a web server and let it run.
All these factors make Frindle a less attractive business long term, so something I've been thinking about are new takes on the agency model that are more accretive and aligned with the companies it's helping. These include:
- Raising a venture fund that's attached to the agency and invests in client companies
- The fund would invest expertise and help with docs/content in addition to capital
- Form Capital does something similar with design help. Not Boring Capital is another example where Packy basically writes long profiles of the companies in his newsletter in exchange for allocation.
- Taking client equity as payment. Writers, videographers, engineers would work part-time for the agency and get a cut of that equity. This is a way for "regular folks" (not accredited investors) to build a diverse portfolio of startup equity, by lending their skills and expertise part-time to a bunch of companies, rather than full-time to a single one.
- a crypto spin on this is the agency helping protocol projects with documentation/content and being paid in tokens. Freelancers are entitled to a share of those tokens. This might actually be easier to implement because I think the idea of "sweat equity" is a lot more accepted in crypto. For example, rabbithole.gg's business model is getting paid entirely in the client protocol's tokens. Another good model to follow in crypto is VectorDAO, a collective of designers helping crypto projects and making investments alongside. I’m thinking about doing something similar for content.
- something that inspired this line of thought was reading Packy's post on the cooperation economy, in particular this passage:
Liquid Employment
Maybe because I’m a full-time newsletter writer and don’t work for a company anymore, but I can’t shake the idea that careers will become a lot more fluid in the years to come.
Pre-COVID, showing up to the same office every day made it hard to work for a second employer. But when another job is just a Slack workspace away, it becomes much easier to work multiple part-time jobs.
This flexibility will significantly increase the opportunity cost of choosing an exclusive employer. Every decision to spend four years vesting at one company will mean shutting off hundreds of other opportunities.
Investors would never choose to invest in just one company; the risk is too concentrated. Instead, they build portfolios. Over time, workers will invest their time in a similar way.
Currently, liquid employment is largely impractical for workers and employers alike. But the same thing could have been said about remote work at one point. Spreading risk over a few companies makes sense for employees. That means that the companies that want an edge to hire the best people for a given role will eventually adopt it.
When I wrote that, I assumed that people would work for multiple companies at once, in a role somewhere between contractor and full-time employee, and I still think that’s a possibility for many people. But I now think my view was too limited.
What Liquid Work provides above all else is optionality. That may mean working for a couple of companies simultaneously, but it might also mean working for yourself, teaming up with others for time-bound projects, investing as a group, and contributing to a DAO in an area of interest. It’s fluid.
When I was reading this, I really felt that Packy was writing for me. I've always been a generalist — a developer, a writer, community-organizer — in a way that felt both extraordinarily powerful and wildly unsuited to traditional work. I sort of compromised by working full-time as a developer and pursuing a side hustle in journalism. But it always felt like I was wasting some of my talent, or making a suboptimal financial decision. One of the things I want to explore with Frindle is whether some of the tradeoffs we take for granted in our careers — ownership for flexibility, for instance — are really so inviolable.