SiteArcade

On Oct 1, 2022, I made the decision to shut down SiteArcade. It was bringing in $1k MRR, but growth had been completely flat since launch. I found the following issues:

• The author market should be B2B, but it behaves like B2C. It doesn't think professionally. It balks at even very, very cheap price points.
• The feature requests were all over the place. They wanted Wordpress + SiteArcade's unique functionality. And I wasn't going to rebuild Wordpress just for authors.
• Authors saw a pro website as a vitamin, not a pain killer. Even though a website is how you sell direct, own your own audience, and convince others to take you seriously.
• Authors are too non-technical. Many are old. Technical support cost more time than I was getting paid for a yearly subscription.

All these things together persuaded me it was time to quit. So I gave every author on the platform a full year to migrate, even extending some authors plans to my kill date.

I decided not to sell because:

• Because of the problems, the valuation was going to be very low.
• I didn't think it would be worth the time to sell.
• If a buyer actually made the product succeed, I'd be pissed.

Instead, I focused on researching my next project. I tried to put everything I learned into making better decisions, and for the most part, I nailed it. (Not that I didn't hit other pitfalls!).

That product is BrowserCat. It's a hosting platform for headless browsers. Check it out.

Like any traversable structure, when it comes to developing a complex infrastructure, you've two main methods.

Depth-First Development
In this style, as you figure out your requirements, you drill down to the very deepest level of your stack (typically the DB), complete the work there, then complete work on its parent, then its parent, and so on, until you reach the UI. Then once you've completed that very narrow piece, you drill down again, and again, and again.

This approach works really well on features where you know exactly what the feature set is, and how to implement it. For instance, let's take a contact form. You know at the very base, you need to interface with something that sends email (node-mailer, AWS SES, etc), you know you'll need an interface that accepts the typical email parameters, you know you'll need an API endpoint that sanitizes data and avoids spam, and you know you'll need a form on your site to send the message.

If the feature you're working on is that obvious, depth-first development is the way to go.

Breadth-first Development
In this style, you start at the very top of your app, using UI development to spec out the full set of features required to meet your user's requirements. Then once you're sure you've fully got a handle on how the feature should behave, you drill down, tackling all of your API endpoints, then all of the services they require, then any database, file stores, or external API integrations below that.

This approach works well when you aren't sure you've captured the right behavior or functionality in your brainstorming. It happens more often than you think. After all, there's only so much you can discover with mock-ups and spec docs. There's bound to be gaps. (And even if you do capture all the features, it might turn out the interface you designed is more clunky in practice than it is in design. Often, this can mean you need to rethink the structure of your data, which can have consequences rippling down your stack.)

Which, when?
More often than not, I've found breadth-first the way to go. After all, since you're designing for users, you should start from what they'll experience when using your app, then drill down from there.

The few exceptions to this rule include well-trod feature requirements (as described above), and also heavy, localized code. For instance, depth-first was essential to building an SDK for using Github as a markdown database for our blog. This piece required a few layers of logic to get right, and (per the above rule), the ultimate interface was well-known, matching the API for just about every data-storage solution.

Though I naturally gravitate towards breadth-first dev, for some reason, in my desire to "do things right," I tried to go depth-first for everything in the early months of development. It worked on occasion, but mostly it made things 10x more difficult. The lesson? Use the right tool for the right job.

These are bad:

• Perfectionism
• Premature optimization
• Fighting with your libs

I had this idea that I should build this thing to be as future-proof as possible. I knew I would be working on it alone for a long time, and I wanted to be able to move fast without breaking anything. An admirable goal!

For our core tech, I chose some pretty stable choices. Not too young, not too old. Full-stack JS. And that was wise.

But I decided on a few major deviations all at once:

• Everything AWS + CDK infrastructure as code
• Lerna monorepo
• DynamoDB
• TypeScript

I'm certain I lost a few months of dev time for these choices.

At the time, the CDK was buggy as hell. Or else all of it's bugs were related to exactly the things I needed to get set-up. Either way, I'm really happy I'm using it now (because it's truly awesome), but I would have been much better off waiting until I felt the pain of managing a slew of cloud resources before I started with it.

Lerna would have been great (and may be great now), but again, at the time, there were some major problems getting it to play nice with NextJS. The number of hoops I had to jump through, just to tear the whole thing down. Ugh. And the thing is, now I can really use a mono repo to save having to make a zillion shared packages... but I'm afraid of losing any more time.

Over the long-term, Dynamo has turned out to be as promising as the docs suggest. However, I really wish Aurora had been accessible outside the VPN when I started, because I would honestly still prefer a relational DB. Probably, I should have just looked for serverless-friendly relational option. But I'm sticking with Dynamo for now.

TypeScript, I don't regret even a little. Out of all the new tech, I can only be sure TS saved me time. And it really, really has. I have hundreds of thousands of lines of code (as of July 1, 2021). There's no way I could have maintained it all myself without this help.

All this to say, use what you know and upgrade... later!

COVID hit. My husband is from Spain, so we hunkered down in Austin before most of the US gave a damn. We stocked up. We waited. We were gonna be fine.

But at the same time, we were hearing first-hand reports of people dying in Spain. Things looked grim, and my husband was upset his old, not-so-healthy parents were so far away.

Then the virus hit NYC, where I'm from, and I started hearing the same things from everyone I know.

And so with all the time in the world, we found it hard to get things done. Not like we stopped trying, but it didn't feel good to be thrown off our game just as things were getting started.

Still, we picked ourselves back up and got moving.

We had a plan, we had a prototype, and we were finally ready to start. So we started.

We divided the work thusly:

1. I did the coding, basically all day.
2. My husband did a mix of copywriting, business setup, and further research.
3. We met twice a week to push forward our product ideas and plan our immediate next steps.

It turned out that after a very short while, we were having too many meetings. We were planning things we weren't even sure were going to happen. And we were having a few too many fights for two people who spend 24/7 with one another.

So over the course of the first few weeks, we learned to avoid meetings. Instead we gave feedback within our project management tool. And we only bothered one another for urgent questions.

Strangely, we were living in the same house, but when it came to the business, we had gone async!

While we were laying out our battle plan (and learning what a good one was), I made a rough prototype of the product. It had all the basic features, but was buggy and ugly as sin.

Even still, I was able to whip it up in about a month. This turned out to be a great motivator, considering we were very concerned about the scope of the project.

However, the prototype also blinded us to how much work was really involved to getting it ready for actual users. There's a big difference between a POC and an MVP.

Stupid people learn exclusively from their own mistakes. My husband and I wanted to do a bit better.

We researched the best resources we could find on bootstrapping a business. At first, this was more traditional content like The Lean Startup, but we quickly found our tribe with bootstrappers, indie hackers, and micropreneurs.

We made a list of all the books we wanted to digest and we subscribed to a bunch of podcasts, listening through some choice back-episodes. Every week, we prepared book reports for one another, and when we found a really good resource, we both went to the source.

At the same time, we were brainstorming functionality, figuring out pricing, and trying to reduce our MVP to the very bone. This went on through the holidays and the first few weeks of January.

If we hadn't done this step, I know we would have made far more errors than we did. In fact, we probably would've given up.

The one problem I always knew with SiteArcade was that even the MVP was a huge undertaking technically. We were going to be competing with Wordpress, so our editor had to feel just as professional, even if it had far less features.

Compound that project with having a stellar website template that was just-flexible-enough to express each author's brand, and a sign-up funnel that hand-held these very, very non-technical users, and the great sales pages that every startup needs... It wasn't the kind of thing I could make progress on in my spare time.

I'd been saving for a while to pursue a startup, and since we had the green light from our audience, I asked my employer to lay me off so I could get the severance package and unemployment benefits while I got to work. We had a good relationship, so they gave me a rather good deal.

But we still wanted to make sure of one more thing...

We organized groups of 5-15 authors at a time, pitched for a few minutes, then dug into what they really wanted their website to do. We did this twice a week for months.

These chats always ran long. Everyone was eager to brainstorm. The same issues came up again and again. Some we expected, and some were totally new.

The most important takeaway was the consistency of the problem the authors described. Websites are time-consuming, technical, and don't do what you want them to do without devoting far more resources than the average author has.

So we knew three things:

1. Authors really wanted the product.
2. They cared more about saving time and money than about aesthetics.
3. The MVP could be feature-poor, so long as it was cheap, easy, and self-updating.

Cut to three years later, the idea for SiteArcade was still on my mind. I released two more books, Graffiti Magic 1 & 2, then hit a wall. Writing books is hard enough. Marketing them is another full-time job in itself. Especially if you write weird stories.

In any case, I was burned out on writing (for profit, anyway), and even after three years, I was still thinking about the idea for SiteArcade. I'd floated it to many of our (me and my husband's) author friends, and everyone wanted it.

Even still, I knew SiteArcade would be a huge project with no easy MVP that I could see, so I wanted to make sure it would really be worth it.

It was time to do real market research.