Building Particl

I’ve been working as an engineer at Particl from Oct 2021 to the present. It’s been a bit of a chaotic and wild ride, and it occurred to me I’ve never taken much of a chance to reflect on all the lessons I’ve learned.

Some of the learnings are short and simple, others are trite and obvious, but I think all of them are worth recording for one reason or another. You can get an idea of what the early stages of a company are like from business school and self-help books, but there isn’t really a great substitute for simply iterating.

Work is work

It is actually very hard to make money. Early on we hung up one of these flags in our office:

Schlep work is what pays the highest dividends, and if you’re willing to get your hands a little dirty, you can make something worthwhile.

Speed is of the essence

Just like compound interest is all about the number of times you compound, startups are all about the number of times you can iterate.

We built a lot of tools & features that were not well received by customers that we immediately scrapped. If the time it takes you to build something new is small enough, there’s a very low cost to failure.

Iterate away, or run out of runway.

Ambition + naivete > experience + arrogance

Our team is comprised of almost entirely 20-somethings. Some dropped out of college, others probably should have, and all of us aren’t FAANG veterans or leetcode champions.

At past jobs, when I heard the smartest guy in the room say “oh no, there’s no way we can migrate all 200TB of data into a new database in less than a month”, I believed them. At Particl, we’ve done it three times now (Redshift → Dynamo → Aurora → SingleStore).

I actually have started to believe that experience (with the wrong priorities) can start to work against you.

You don’t need narrow titles

There is a whole class of job titles that are just silly at early stages.

1. DevOps engineer
2. Product designer
3. Product manager
4. Project manager
5. SEO expert

When people say titles are stupid, they can mean one of a lot of things, but I think they’re stupid because they pigeonhole responsibility for someone into a tiny category that they don’t let themselves operate outside of.

One average person can spend a couple focused days learning from examples around them and get to an output that is ~80% of what an “expert” title-holder can do. Surprise surprise, you can do things without a wireframe. Believe it or not, your average engineer can stand up a continuous integration pipeline. That same engineer can even write out a spec for a new feature if they try, the problem is most just won’t unless they’re forced to.

I’ve observed many “experts” actually get things done slower, maybe to justify their title? We haven’t had any of the above titles at Particl, and other ones we have had have felt like their impact was contained to the domain they painted themselves into with their title.

SEO is really good, actually

As much as it feels like a snake oil industry, SEO is actually a great way to get more users.

It’s almost free, not super hard to get started, and delivers actual results. The problem is when you pay a consultant gobs of cash to do something they can’t quantify to you.

Just start getting a lot of pages of really good content online, wait, measure, rinse, repeat.

One week on an SEO initiative resulted in 1000+ new signups over the next year for us. Before that, our organic traffic was close to 0.

People pay premium prices for premium products

You can fake customers into thinking you are bigger than you are by building something exceptional. People are used to pattern matching and thinking that well-built software can only come from well-funded mega corps.

Sweat a lot of the small stuff, and you can punch above your weight class.

We signed up a lot of solid brands (Vuori, Gymshark, SKIMS, Cozy Earth, Ivy League schools, fortune 500 companies, etc.) early on by demo-ing them an app that didn’t feel like an MVP with the minimum set of features.

I made an effort to build a similar attention to detail into our website, so it would feel like you are signing up for something premiere. Anyone can slap a WordPress template on a domain or pay $50 for a Framer site, so a bit of custom code goes a long way to convince people that you’re not just another cookie-cutter SaaS.

Write things down

Write everything down. A lot of decisions get made in DMs, and the game of “he said, she said” is a great way to get whiplash.

It’s so stupidly simple, but so impossibly hard to do by default for some reason.

I got teased for this idea at times because I would harp on it so much, and it led me to writing down more about it in a different essay.

Writing scales infinitely, is proof of work, and leaves a record for when future you can’t remember what decision you made on how to deal with customers who lost access to that one niche feature.

The only case against writing things down is if you’re committing fraud, which itself makes the case for writing things down seem even stronger.

Copy the winners

The best athletes copy the diet and training regimens of other world class athletes. I think it’s fair that the best entrepreneurs copy the business models of the best businesses.

If another business has made some decision, there are generally 2 possibilities:

1. They are wrong, and haven’t been around long enough to die
2. They are right, and it’s a decent idea

I’m not talking about straight up plagiarizing your competition, I mean learning from businesses that are like yours. Particl sells B2B software + data, we learn very different lessons observing other businesses that sell B2B software + data vs companies that sell open source software to consumers.

This is true of business models, but for cases like UX, you can learn from lots of other software. In those cases too, it makes sense to copy vs pouring time into all sorts of research that will maybe lead to marginal improvements.

Tech is a Ship of Theseus

A modern tech stack probably needs to evolve to meet the needs of the business, as it adapts it might not even resemble the original code. Code should optimize for:

• delete-ability
• refactor-ability
• safety (via types, tests, etc.)
• and whatever else gives you confidence to make changes

We have ripped out huge portions of our codebase and started over on entire features multiple times. We’ve never rewritten the entire thing, but we have rewritten significant portions.

We’ve made decisions that have been wrong, or were made before new technologies came around to make them the less optimal choice. These are a few of them:

• poetry → uv
• Black → Ruff
• TypedDict → Pydantic
• Lambda → Railway → Render
• ESLint/Prettier → Biome
• API Gateway → FastAPI
• Lambda → Docker
• SES → Loops → Resend
• Amplify Auth → Clerk
• Next.js → Vite + TanStack Router
• Redshift → Dynamo → Postgres → SingleStoreDB
• JavaScript → TypeScript

When we needed to change them, we could. Sometimes it was painful, but it makes your code more delightful to operate in when you can mold it to meet your needs or remove painful thorns from your side.

The correct technology for your app usually comes down to an answer of “it depends”, which means that your app might go in the exact opposite direction of my list above. The point is that you should be able to make the choice. Try to avoid tying yourself too closely to a technology that could constrict your own agency to change it.

The remote work debate is nuanced

With the best, intrinsically motivated people, remote work is a killer superpower. It works best when everyone is remote.

• You can have someone online all hours of the day
• You can hire the best talent
• and you don’t have to fight soul sucking commutes twice a day

However, hire a couple freeloaders and it’ll slow everyone down. People tend to match the effort of the people around them, and even a little poison makes the whole hive sick.

Working in office is also an incredible superpower.

• You can build a way more connected team that trusts each other more
• You can make decisions & iterate faster
• and you lose a lot less great people to turnover because you aren’t competing with the entire world for talent

Combine the two and you get hybrid work, which I think combines the worst of both worlds. Decisions that you’d like to make faster with people in office get slowed down by clunky processes to incorporate remote people (“can everyone see my screen?”), or remote workers get excluded entirely. Culture is diluted, because so few people are in office most of the time. You have to pay for an office space, and you still have people complaining about their commute half the week.

I came from remote-only companies that were awesome, worked hybrid for a while until I saw the downsides, and now work almost exclusively in office. Particl’s policy is entirely in office.

The midwit meme is a true reflection of the world

You don’t always know which side of the distribution you’re on, but Occam’s razor won’t lead you astray.

The simplest thing can be simultaneously foolish to the average person, and the wisest decision when reframed.

The Particl logo is just 4 squares offset to make a “P” shape. It was intended to be easy to render in SVG, and be a single color. The name Particl was just the only available .com domain we could afford that also fit a sort of techy theme and didn’t tie us down to a specific industry if we needed to pivot.

We could have paid a firm to design a logo, but it would have cost us an arm and a leg for what amounts to a small 2kb .svg file that we could have made ourselves. Are there truly iconic logos out there worth the cost? Maybe?.. but they’re probably not the result of some expensive process from a design firm.

We actually did pay some firms some money to help us out, and ended up with some of the worst possible brand concepts of all time.

The paradox of purpose

Building something is worthwhile, but at the same time it’s also just a job.

There are a whole lot of other more important things to be doing with your time: raising kids, serving your community, etc. Unfortunately, doing those things usually requires you to have the time and money to allow you to, so it’s worth it to put a little heart into your work.

Keep in mind, that whatever it is you’re building, it probably won’t be the last, and it probably won’t be around forever. That should simultaneously free you from the stress to make it perfect, and give you some pride that whatever you learn can carry on to the next thing.

I have really, really loved building things at Particl. I’ve worked on consumer APIs, growth + marketing, payment processing, frontend architecture, database design, UX design, data pipelines, and then some, and I do all of it pretty average. At the end of the day though, I really don’t care that much about e-commerce and retail.

I don’t think I’ve found my life’s work building B2B SaaS with the boys, but at the same time I’m sure glad that I did!