I actually wrote this memo before I drafted the 

. The memo felt like how I would naturally explain this.

I came up with this structure just from having conversations with angels and trying to put myself in their shoes. Why should I part with my money? What would I want to know? 

This is a bit more focused to angels and investors who are going to be earlier. There’s going to be a little bit less hard numbers. I was thinking through what you need to know to make this a good angel bet, where people are putting a much smaller amount of money and they’re planning to do a whole bunch of investments. The lens that I came at this was, “Do these people know anything about the problem? Is it really a problem? And does the team have the expertise to do it?” 

The checkmarks actually were similar for the pre-revenue raise. There was a bit more diligence because it’s a larger sum, but they were still asking the same questions.

The big thing that will be different when we raise an A is that we’ll need to show that we have growth and a working growth motion. At that point, if you have product-market fit and a working growth motion, you’ll need to be able to show it and have good answers about your growth engine and some sort of story about retention.

I default to extreme honesty and candor when talking to investors, which sometimes does me a disservice, but then the people that like that are the ones I end up wanting to work with anyways. It’s important to realize that you’re selling. The way I looked at it is you’re selling a useful commodity out there. VCs can’t exist without entrepreneurs. It’s important to remember that.

The amount we were trying to raise changed as we went. When you start off, you don’t know if anyone’s going to give you anything. Then you test the waters and figure out it’s a non-zero amount. Then you have to think about what type of company you want: two people bootstrapping? Going faster but with the risk you splat harder if you don’t pull out of the dive? At the end of the day, raising money felt like a bet on the team that we would be able to figure something out eventually. We wanted to be able to take more than one shot on goal.

Looking back on this proposed timeline, everything’s been a little slower than what we proposed but it’s pretty close. We’ve done the bits we’ve had full control on. We’ve shipped things we said we were going to. We were thinking by this point, we’d probably be a little bit broader, but surprising no one, more focus is better and getting the attention of potential customers is hard. We’ve focused a little bit more on working on the core and focusing more on content and marketing than it said in the memo. This all feels directionally correct but getting initial growth motions takes a little longer and we’re still in that phase.

Jeff Dwyer

Writing this investment memo really helped me refine my narrative for Prefab’s pitch deck and our successful fundraise.

Prefab means “already built” and that's what we do.

 We find the core services that super-charge the best engineering teams and make them usable at any org. These are services like dynamic configuration, feature flags, authorization, entitlement & product configuration. Top tier engineering organizations invest heavily in these capabilities and have great solutions, but today they are unobtainable or prohibitively expensive to be ubiquitous.

At Prefab we harvest these end-state solutions and provide them as a service so that every engineer can spend their time on work specific to their business.

AWS turned cloud computing from a huge challenge into a solved problem and our mission is to do this for the next layer of services on top of that infrastructure. More than 10% of total engineering effort goes towards core, non-business specific technology. If it’s not specific to your business then you should use something great that’s already built and that’s what we provide.

To invest in Prefab, first you need to believe that this pain is real. Many of you have experienced this directly, frustrated that engineering seems stuck putting effort into something you’ve seen solved someplace else.

If you’ve been an engineer exposed to great tools at top tier orgs, the come-down of working in the real world is brutal. Your tools to quickly operate and tweak your systems while they are running are gone. There is no happy, opinionated path through micro-services. It’s 2023 and these should be solved problems, but most organizations are still running on duct taped DIY systems.

The next thing you need to believe is that this is a solvable problem, that good solutions do exist, that a general purpose solution is possible. It’s reasonable to wonder whether every organization’s problems are too specific to be solved generally.

The good news is that in reality these systems evolve and converge to the same place. Companies start off with bespoke point solutions, but over time we end up building the same thing. Google has published a 

 on their authorization and it's the same system that supports the ease of use of Google Photos, the power of Google Drive, and the massive scalability of YouTube. Large orgs inevitably have to solve the superset of problems and the design of these systems converges to solutions that are scalable, flexible, and powerful.

Prefab isn’t writing speculative solutions. We are harvest these battle-tested services, providing them as a service, and adapting them so they can work for orgs of all sizes.

If the pain is real and there are known solutions, the next thing you need to believe is that we are capable of building it.

The three founders are specially suited to this problem because we couple deep experience with how good it can be and real world experience about why so many organizations struggle to get to Valhalla. 

 so passionate about this space because these are the tools I desperately wanted to buy when I left HubSpot and took ezCater on its hyper-growth journey. In my time at ezCater we grew from an engineering team of 10 to 120, transitioned from a monolith to micro-services and built a unicorn. I built 

 0 to 1, started our first growth team and built deep marketing / eng partnerships. Having 

 available for that journey would have saved countless hours and dollars and allowed us to run a smaller and faster engineering org with even better results.

I’m joined by two unbelievable co-founders that I’ve known for 10+ years. I've worked with 

 at PatientsLikeMe, HubSpot & ezCater and he's also led teams at Dribbble & Wistia. You will not find a finer fighter s/pilot/engineer/ anywhere in the world.

 is a backend and reliability guru who operates like a leverage seeking missile. He gives us a deep understanding of what it takes to operate a top-tier engineering organization, coupled with a knack for immediate time to value. He led Contacts, Analytics and Email teams at HubSpot.

We've lived with and enjoyed these systems at scale, and seen first hand the pain of rebuilding them from hand when we left HubSpot. Our experience places us in the sweet spot to be able to solve this at the scale required, while still being simple to adopt.

We're joined by our "Friends of Prefab" Slack community that is bringing together a curated group of architects and engineering leaders from our network to make sure we have real time access to the best thinking from across tens of orgs.

As we build this, the next thing you need to believe is that we can get it installed and used. Sometimes the best plan is a really simple one. Our plan is to just sell the best product for a lot less. We win when we are the ubiquitous solution for these tools.

To do this, we need to be easy to trial and adopt. That fits perfectly, because at the end of the day, developers make the choice for which product they are going to use. If they can land on a page of content that describes their problem, quickly trial it and get it in production and see its value, we win. Even at large enterprises, the first step is getting the architect or staff engineer to fall in love with the solution.

A perfect example of our introductory wedge is Prefab's dynamic log levels. Every organization at scale complains about the cost of their logging aggregation. Our system lets customers add a library, and immediately dial in log levels on the fly, allowing them to reduce logging overall but retain the ability to dive deep when necessary. These wedge user cases let users trial Prefab in a low risk, high reward scenario are our PLG onramp.

The last thing you need to believe is that we can grow by building a self-sustaining engine of excitement and change.

Again, our strategy is simple. We need to give our customers super powers. As luck would have it, this is exactly what these tools do. Being an engineer at HubSpot was amazing. Using dynamic configuration in production feels like being able to tug on the strings of reality.

“I've got a live binary. How do I operate this thing easily? Like, how do I change log levels? How do I configure the thing? How do I debug it? How do I actually treat my code as a living, breathing creature rather than just a static asset?

And then how do I bring myself into that ecosystem and interact with this, like the Zoo of creatures.” - Head of Eng Advisor

Operating in this way let my HubSpot team of 5 compete against entire other companies. Great versions of these tools retain engineers and keep them focussed on delivering customer value.

So do you think there is a world where we can finally stop rebuilding these wheels? A world where developers get to focus on solving actual customer problems because they start on day 1 as if they had the best core platform team on their side? I think this world exists, our fabulous early engineering angels think it exists and I am so excited to make it happen.

[Redacted list of eight angel investors with top engineering credentials]

 to help us hit 2023 with everything we've got. To date we've built an initial version of dynamic configuration, feature flags and dynamic log levels so that we can verify our architectural and reliability decisions with prospects.

In Q1 we are making what we've built fully production ready and will be onboarding our first users. We are shipping Dynamic Configuration, Dynamic Log Levels and Feature Flags in early February. We have interested pilot customers lined up and will be partnering deeply throughout February to get them started. In conjunction, we will also be launching our growth efforts to iterate and refine the messaging that most resonates with our users.

Q2 will be a focus on rapid iteration with our core functionality and messaging. We’ve seen a lot of interest in dynamic log levels, but config is a versatile hammer with a ton of uses. We’ll be blogging about some of our favorite config uses: modified Kafka handlers, cache invalidation, local development and http traffic reliability. We’ll also address the FeatureFlag market and convert some major (unhappy) customers from the competition.

, we'll be building out the core internal facing versions of the larger vision around entitlement and product configuration. Our goto market can now include case study verification about organizations that have switched to Prefab and we’ll expanded security & compliance work so that we can be adopted at any organization.

By the end of the year we’re aiming at X Enterprise, X Large, X Medium and X Small users. When we can achieve this, we will have unbelievable momentum supporting us into 2024 and an A-round to fuel our growth.

Our key Angel Investors have been selected to give us a huge leg up as partners and advisors. Combined, they bring a amazing depth of experience in Growth, Startups & Strategy.

[Redacted list of 10 strategic angel investors]

Please contact Jeff Dwyer if you would like more information about investing in this round.

Investment Memo from Prefab

Prefab Cloud Investment Memo

There is Pain

There is a Solution

Sign up to see more