The early days… when we “saved money” by only buying two chairs (spoiler: we needed more than two chairs).

Startup techniques for Getting Things Done: pre-Customer to Customer.

Dark is changing how developers write backends and operate infrastructure. Interested in trying it out? Sign up here and tell me a little bit more about what you want to do in the “Anything Else?” Section. Every sign up goes straight to my inbox (you can also email me

Ultra Early Stage Companies

Not very many people write about the very early days of their own startups. That’s for good reason: you’re desperate to find customers, not write about what you’re doing¹.

What is written on “early startups” focuses on a few buckets:

The downside is these ideas often sound like “quick fixes” rather than all the things you really have to do to get through the early days.

Get a Customer ASAP

If there is a quick fix, it’s getting a customer as quickly as possible. Customers create momentum.

In a consumer business, you can do this by making a “Wizard of Oz” version of your product. At the beginning of Lola, I spent a ton of time booking hotels for people via iMessage and Slack. The time it took me from having an idea to testing it could be on the order of minutes or hours.

The equivalent for a b2b SaaS business is selling a manual or human version of what you want the product to be (often in the form of a spreadsheet). You could also sell a vision of what you’re doing and get a pilot contract signed to build around.

If you can do this, do it!

There will always be a time before you have a customer.

That said, there will always be a time before you have a customer. Many successful companies didn’t spend a ton of time thinking about this. They got a customer quickly, and moved on. It could be one of the above techniques, having a side project with users before a business, or a really great market. That’s why we have a lot of good writing about iterating once you have a customer, and about software development as you scale.

But… not having a customer is hard. This phase kills many would-be founders! There’s a million things you can try, and the most important thing is to stay focused and keep moving. The world changes quickly as you learn more.

Before you have customers, you need to find (or build) a way to create momentum.

At Dark, we got to work pre-customer for much longer. Why? Building a software development platform is vastly different than building a consumer product. There was no good way to Wizard of Oz what we wanted to do, and telling someone “it’s cool, we’ll magically provision infrastructure!” generates a lot of skepticism.

You could end up in a similar place if you’re in a heavily regulated industry, or there’s a high barrier to entry.

Since we knew this would happen for us, we were very conscious about it. We consciously avoided “playing startup.” If you aren’t familiar, playing startup is doing all the things that look like being a startup: without building and shipping for real people.

We wanted to get to a product our first customer could use.

Techniques for building pre-Customer.

We ignored most other things, and focused on getting to our first customer. Some people would say “just build stuff!! Don’t worry about how you do it!”

That said, “no process” probably just means an implicit, unexamined process.

It was important to us to do things well, to get out of “pre-customer” and into “customers” as quickly as possible. That meant finding the best tools to get there.

In order, the tools we tried were: pomodoro, absurdly tiny projects, hypothesis spreadsheet, building something real, and hiring a customer. Our techniques are mostly focused on software development, but many applied to my non-software-dev work, too.


At the beginning of Dark, it was just Paul and I. We sat around my dining room table doing work together.

I did really boring stuff: ordered whiteboards, configured SaaS products, and spent hours trying to figure out an issue with getting us registered with the State of California to pay taxes (it turned out to be an obscure human error we’d made in Stripe Atlas). This was particularly challenging because I was coming off of two years of management that involved very little “do these extremely concrete tasks.”

Before we had the whiteboard, we took the glass top off of my desk and used it as a whiteboard.

Paul spent a bunch of time writing boring boiler plate code (ironic, as we’re building Dark to prevent developers from doing that!)

While we were doing things that were important, neither of us was doing the work we love most. It was easy to get worn down, feel like we weren’t making “real” progress, or want to go brainstorm future product ideas instead (see whiteboard above).

Pomodoro helped us get through it. If you aren’t familiar, Pomodoro is a productivity method from the late 80s that involves working in small, timed chunks.

  • We worked in hour long chunks instead of 25 minutes.
  • At the beginning, we’d each tell the other person what we were hoping to accomplish, and at the end we’d check in on if it got done.

The real benefit was just having a designated time when we could interrupt each other to ask questions or vent. It prevented us from having an all-day water cooler while still getting to interact. It’s good for individuals, very small teams, and grinding things out that aren’t the most fun or complex part of your job.

We don’t do this as often now, but Paul often reminisces about it. It’s not great during projects that require long chunks of uninterrupted focus, or autonomy over your own time. When I’m doing this alone, I use a Miracle TimeCube (I’ve gotten them for everyone else at Dark, too). You can also use Social Pomodoro.

Absurdly tiny projects.

Once we got to the place where we could actually build things, Dark still had a lot of moving pieces that we could invest in (you could consider a programming language, an editor, or an infrastructure compiler to be a product on their own!)

While I’d been tracking down our EIN, Paul got a very rough first version of everything working (i.e. we could put “hello world” on a website using our core concept of instant deployment).

Unsurprisingly, it wasn’t able to build a full production system, or an interesting application. We wanted to be able to write real code.

But that meant building everything. To prevent ourselves from getting choice paralysis about what to build, we scoped absurdly tiny projects that would never be useful in a real-world context. They were laughable.

The first thing we “shipped” was a language that only had enough features to translate Caesar Ciphers. It didn’t have conditional statements (which was a huge pain given that’s how I wanted to solve the challenge!) I’m pretty sure Paul literally laughed at me when I proposed this.

That said, it had just enough to let us put users in front of our language/editor and get feedback on what they were expecting.

We learned a ton:

  • We got to see how people reacted to using their keyboard vs. their mouse.
  • We learned that small UI Improvements had huge impact on what people perceived about the limited language and platform. (I’d never seen such a dramatic impact, even in a consumer product).
  • We saw how differently people approached the same problem.
  • There’s a ton of anxiety around user testing in this space. “Try to program this” ends up feeling like an interview — it’s an order of magnitude more stressful than consumer user research.

We were able to build on top of the first absurdly tiny project by coming up with new projects that aligned to adding one feature. The second one was making the language able to write Fizzbuzz, so we’d need to think through how conditionals worked.

Hypothesis Spreadsheet.

At some point, we had enough of a product that things were no longer “absurdly tiny,” but we still had lots of areas to explore. During our Fizzbuzz project, we also found ourselves saying it’ll work by the end of the week,” every week, so we wanted more accountability around what was throwing us down. Whatever we picked, we wanted it to be focused on explorations, and incredibly lightweight.

We designed a hypothesis spreadsheet. It started as:

  • Goal: What will we ship this week?
  • Hypothesis: What are we going to learn by shipping this?
  • Outcome

As we worked, we added a few more fields:

  • We added a “why?” row so we could tie the weekly goal back to our overarching premises. What’s the big thing we’re looking for?
  • We added an “unexpected” column for the things that were derailing our progress.
  • We added a “punted” column for items we’d consciously decided not to address.

Each week this took us a few minutes, but really set the cadence for what we were doing and why.

Make something real.

Building upon the tiny projects and the hypothesis spreadsheet, we got to a point where the product could be used to build something. We moved our overarching goal to be “make something real.”

We worked towards making a backend for the RealWorld Conduit in Dark. This meant actively using our product to write “real” code every single day. By picking an existing project that already had a front-end, we weren’t able to avoid things that didn’t work in our project, or design around the constraints we knew our language had.

It was important for us to eat our own dogfood by building something in Dark ourselves first. Things were still painful. To get through the project, we spent a ton of time pairing, and a lot of time trying to keep our spirits up as we documented every issue we encountered. It was worth it when we got to our first demo where we could see ourselves add a feature to a real product, without deploying!

We’ve kept doing this. It’s an extremely good way to stay in touch with your product (“trying a feature out” is very different than “writing and maintaining a product”). I continue to iterate on one of my personal projects in Dark.

Set a high pressure goal.

After we managed to ship ourselves, we wanted to have a real customer. We knew that being the first person to operate a company on top of a new platform was scary, and we wanted to make it worth their while too. We hired an entrepreneur/engineering residence (more on this in a future post). Since we knew we’d be wasting valuable time and money for ourselves, and for our user, if we weren’t ready in time, we wanted to make a solid plan.

We planned out what we’d ideally like to have built before they started. It came out to about six months of work. That’s way too long to work in isolation without getting real feedback. We made a ton of painful cuts to get it down to six weeks. We broke down the six weeks of work, week by week. We created a giant checklist of each item we needed by ship. For six weeks, we lived and died by the checklist.

  • Nothing got done if it wasn’t on the list.
  • We printed it on the wall and everyone was aware of how much was (or wasn’t) getting checked off the list.
  • We hired a contractor in one of our weakest areas to help us move that much faster.

Lots of startups claim that it’s always time for high pressure time, but this is the only way to create motivation. High pressure is appropriate in situations that require adrenaline: when you know where you’re going, and you need to execute quickly. High pressure does not help when you are trying to come up with interesting experiments and decide where to go next.

Having a customer.

Like I said at the beginning, this is the real goal. The average SaaS or consumer business should have a customer nearly immediately. I booked my first plane ticket as a chat-based travel agent at Lola before we wrote any code.

We felt far-from-ready when we finally got to the point of having a customer. It did mean that we knew that the changes we made had real-world impact. It also meant we had to work in a way that more closely matched the tradeoffs we’d make in the long term!

Some of the things that changed:

  • Someone was always on call for anything that came up that was blocking.
  • We had to figure out integrations with external tools.
  • We learned a lot more about bugs in our operations.
  • It was harder to carve out time for larger projects, like changing how our database architecture worked.

Having one customer helped us make the transition to working in isolation, to balancing our priorities and customer needs.

What’s next?

All of the experiences so far were things we tried with a super-early, tiny team building a technical product, before we had a customer. It’s an unusual space, and why we wanted to share the techniques we’ve tried and what we learned.

While I don’t think everyone is building a developer platform, I do think many would-be founders get stuck in the morass of what to do before they get a customer.

Since these techniques, we’ve added three more team members, bringing us to seven (and we have multiple customers).

At this inflection point, we’re looking at some of the classic things that come up as a startup grows:

  • New formats for our retrospective/reflection meeting.
  • Continuing to balance customer responsiveness with longer term planning.
  • Understanding and improving our velocity.

There’s been lots of writing on these, and we’re excited to learn from others and report back on what works as we expand our user base.

¹ AKA Why you are reading this blog post now, and not nine months ago.

Although, I will admit, it is also important to have fun every once in a while:

I made everyone go to the Museum of Ice Cream with me. I’m not allowed to plan our off-sites anymore.

Still here? Dark is changing how developers write backends and operate infrastructure. Interested in trying Dark? Sign up here and tell me a little bit more about what you want to do in the “Anything Else” Section. Every sign up goes straight to my inbox (you can also just email me