Dark and the long term

TL;DR: We’re taking a longer term approach to building Dark. As part of this, we’ve made the difficult decision to shrink Dark’s team, and to change how we build both the product and the company.

Over the last few weeks I’ve been thinking hard about where Dark is and where Dark needs to be to succeed. And I have come to the conclusion that we need a different approach in order to achieve Dark’s vision.

Dark is a solution for the toils of building backends. It’s about removing all the complexity and challenges of building software, all the surface area of Kubernetes and Serverless and AWS, etc. This problem hasn’t gone away since Dark started. If anything it has gotten worse: Serverless has joined Kubernetes as a technology with a massive and complex surface area.

The opportunity for Dark is bigger than it’s ever been.

What Dark is now

Dark solves this complexity by combining a programming language, editor, and infrastructure. This integration removes most of that complexity, allowing developers to “Just code” their APIs and CRUD apps. It’s been in beta for over a year, and early users love it!

Dark is great today for building small apps, such as frontends in React (etc), internal tools, and Slackbots. It’s the quickest, easiest way to make an API on the internet. Developers love being able to see live data in their editors as they code, which we call Trace-Driven Development. They also love the “deployless” concept, where changes are reflected in production — safely — within 50ms of making the change.

People have written so many nice things about Dark it’s hard to keep track, but it typically ranges from “cautiously optimistic” to “transformational” (1, 2, 3, 4, 5, 6). So it really feels like we’re on the right track!

What Dark still needs

Of course, that’s not the full story. For Dark to succeed, we need two things:

1. make coding simple and delightful, without infrastructure or deployment complexity.
2. support all the things which are taken for granted in existing languages and web frameworks.

The latter is an area where we currently fall significantly short. If you use Firebase today, you’re not going to get Dark’s amazing trace-driven development, but you will get a fantastic built-in auth solution. With Dark you’d have to build that manually — and what’s the point of having all this complexity removed, only to have complexity added by having to roll your own auth solution?

Similarly, if you use Ruby, Python, Node, Go, etc, you’ll have a package manager with a huge suite of SDKs for every API out there, making them pretty easy to use. You’ll be able to call Stripe, Twilio, Slack, etc. In Dark we have a few APIs, but have not yet launched our package manager, and so users have to do a lot of manual work (complexity!) to achieve what’s easy in other languages.

We’ve learned over the last while that when people get to Dark, they expect to have these features, and quickly get frustrated without them.

In addition, the stuff that’s great about Dark could do with some maturity. We’ve solved the problems for small applications, but have not yet addressed them for teams of 3 or more, for medium-sized data, and for many edge cases.

Company Structure

This is not an uncommon problem: languages, platforms, etc, take time to mature. But the solutions needed do not map well to our company structure or finances. In order to support our team of 8 people, we have been aiming to raise our next round of funding in around 6 months from now, requiring aggressive growth. And as we try to fill the gaps in the product to achieve that growth, we keep running into foundational product problems that can’t be simply patched in a few months, and whose solution requires a holistic approach.

To put it more bluntly, we have been focusing on growth of a product that has not yet reached product-market fit.

This is the wrong approach, and it will not work. As such, we’ve decided to restructure the company to ensure the long-term success of the vision. As part of this restructure, my cofounder Ellen Chisa will be leaving the company. I have also made the difficult decision to lay off the extremely talented team that was building Dark, in order to provide the time and the cash needed to make these changes.

These are not decisions that we have come to lightly. These are extremely talented team members who took a risk on us and did excellent work. If you are hiring, please reach out to discuss hiring some of the amazing folks we’ve been working with. (The team have found new positions, thanks to all who helped!)

Future of Dark

So where do we go from here? Right now, the team is just me. I am committed to realizing the full vision of what Dark should be. Dark is financially healthy for many years, and there is time to think and to plan. I plan to involve the community much more in Dark’s growth, and slowly rebuild the team at a pace appropriate to the product’s maturity, focusing on a small, tight team that can wear many hats.

As this happens, Dark will still be available in beta. We have 500 active projects, and a trickle (~100) of new users a week. We will continue to provide Dark and invest in its future, though it’s fair to expect that new features are going to come more slowly. And of course I’m the only person on call right now, and the platform isn’t totally stable, so we are likely to see more downtime in the near future. Apologies in advance.

As well as the 500 active projects, we have a Slack Community with 1600 folks in it. We’ve started working on making Dark source-available, and 20 of our community members have already made contributions to the Dark codebase. Folks are excited about what we’re building and want to help, and I’m going to spend time putting the community at the center of how we build Dark.

In the long term, I’ll be focusing on making sure the existing Dark features are robust and well-designed, including the deep work on the language, platform and editor that is needed to support that!

In the short term, there will be a bunch of maintenance work, to stabilize the system and reduce technical and product debt, as well as making Dark easy to learn and get started with.

I’m also going to start to build Dark more in public — support community involvement in designing and contributing to the language, editor, platform, and package manager.

I would ask the Dark community to be patient during this transition. I can’t say that Dark is going to be perfect in the near future, but I can say that our focus is on ensuring the success of Dark and its platform and community, and I hope you’ll stick with me while we get there.

If your company is hiring, please reach out to discuss hiring some of the amazing engineers, designers and product folks from the Dark team. (thanks to all, the team have all found new positions)