Hey! I'm the author of this blog post. If you have any questions, let me know!
One of the lessons I omitted (because the post was getting a bit long), is we started off as cross-platform (Slack, Teams, and Discord) but in the end we decided to focus on a single product.
In retrospect, we've struggled to decide if that's a lesson to learn. Should we have started with a single platform? It certainly makes it much faster to build for a single platform. But at the time, we really thought the cross-platform chat-ops would be a distinguishing trait!
Just wanted to say that I like your writing style. It's approachable and entertaining to read. Good luck with Abbot and thanks for sharing your lessons learned!
> Balance your early engineering and infrastructure with achieving Product Market Fit
No, not really, you should focus way more on the latter really. We devs love the first tho.
e.g. comment from your original post 12mo ago: "Super stoked to see you launching after working on it for so long!" -> how much of the code you've written was necessary to come to the realization you eventually came to? Based on the way you described your trouble selling, seems like very little to none.
- Azure seems like a bad choice (running out of capacity lolwut)
- corollary to above: don't get too attached to where you worked. Seems like your original idea was heavily based on something u saw internally. Just because something works well at one (usually large) company you worked at doesn't mean it serves a widespread market need (I've been burned by this).
Just some thoughts, hopefully your pivot is successful!
> No, not really, you should focus way more on the latter really.
You're absolutely right. I think I should have phrased this as "Don't completely neglect your early engineering and infrastructure." Some choices could inhibit our ability to achieve product market fit.
> - Azure seems like a bad choice (running out of capacity lolwut)
I think the pandemic created supply chain problems that affected a lot of companies. There's a lot of reasons to like Azure for me. I'm familiar with it. They focus a lot on developer experience. But this one issue really hit hard and definitely makes me want to be more flexible in how we deploy to the cloud.
> - corollary to above: don't get too attached to where you worked.
Ha! Yeah, we really loved the GitHub way of working. Turns out, GitHub had a unique culture and it doesn't necessarily translate over to whole market. I wish I had included this in the post.
> Just some thoughts, hopefully your pivot is successful!
Can you talk a little more in detail about your tech stack? Perhaps it would help more readers like me who are curious given your history in the .NET space.
Sure! Because of my background in .NET, it made sense to stick with what I know. I don't believe the tech stack makes or breaks a product (unless you choose egregiously poorly). A product's success is primarily determined by how well you hit product market fit.
That being said, a good stack that you know well can affect how quickly you build and how quickly you can adapt the product to changing market conditions.
So here's what we use:
- ASP.NET CORE( - Primarily ASP.NET Razor Pages for the web app. ASP.NET MVC Controllers for the internal and external APIs we support.
- C# - We try to stay on the latest version. The recent pattern matching improvements alone make our code so much cleaner.
- [HTMX](https://htmx.org/)\* - for front-end. We're not at the point where we feel we need a heavyweight front-end framework like React. We like the 37signals approach of shipping "HTML over the wire". We're also big on Web Components. That's a result of our [GitHub heritage](https://github.blog/2021-05-04-how-we-use-web-components-at-...).
- TypeScript - for our front-end JS. This is a recent addition. Most of our JS is still ES6.
- Azure Database for PostgreSql - PostgreSql is rock solid and great for storing all kinds of data.
- Azure Functions - we support three types of custom code skills that customers can use to enhance and customize the bot : JavaScript, C#, and Python. We run these in Azure Functions.
- App Insights - We use this for logging.
- Azure Managed Grafana - We have a nice Grafana dashboard based off our App Insights logs that helps us get a birds-eye view of how everything is doing.
- Azure App Configuration - For feature flags.
As you can see, it's pretty heavily Microsoft based. Part of that is my background. The other part is we got a lot of Azure Credits when we joined the [Microsoft for Startups](https://www.microsoft.com/en-us/startups?rtc=1) program. So it made fiscal sense for us to stick with Azure.
I do like that we can manage everything in a single portal. But some of these tools are not best-in-breed as we will be looking at other options down the road.
> The other part is we got a lot of Azure Credits when we joined the [Microsoft for Startups]
Wow, Microsoft must have really drowned you with free credits to choose Azure. We also tried Azure 2.5 years ago when my small team (3 founding devs) started with our startup, but after 6 months of constant problems, broken services, outages, and completely out of the blue unexplained service failures we had to give up. We wasted a lot of engineering time on bending our app to Azure's needs and still had issues. We eventually migrated to Google Cloud and hadn't had any problems since then. I am not kidding, the first 6 months we must have spent at least 70% of our time on issues which we wouldn't have had on AWS or Google. Azure really under delivered on all fronts. Things looked extremely promising and then when we used a service we realised that most useful (often necessary) features were behind extremely expensive tiers and then it meant we had to either take huge hits on our hosting costs or build weird workarounds. We didn't want to go against Azure and often chose to pay, but even the higher tiered services then started to act up and often result in totally unexpected behaviour. Good luck to you though!
I have experience the other way around. AWS was utterly holding us back and we gained a lot of speed when we switched to Azure. Azure has changed a lot over the years though and a lot of features behind a premium tier are now more available to lower cost tiers. Comparing something to 2.5 years ago is a long time in the fast moving cloud world.
I remember VCs telling me to be a platform, not a product. "Look at what FB is doing!" It made sense for FB, but that doesn't mean it makes sense for everyone.
A sticky platform will be stickier than a sticky product. But that doesn't mean every product should be made into a platform.
The VC's point was that FB was moving to be a platform, and I should too (despite having approximately 0% of the number of users that FB had at the time).
I don’t think you understood my point. Being an advertising platform is good for facebook. But I don’t use FB for that reason (actually it’s a negative) I use it to keep up with my friends and family, and their kids.
FB started by “selling” access to the freshman* picture book. They only became a platform later.
* hopefully a less sexist term is used these days.
I don't think you understood my point either, so I guess we're even!
They used to just be an app, and now they have an ecosystem of products (Whatsapp, Instagram, etc.). I wasn't referring to the fact that they also run an advertiser-facing platform at all. I was just pointing out that they started as a single product and have expanded to being a larger platform, with all the network effects/benefits that such growth entails. That's great for them, at that stage.
But it doesn't make sense for all earlier stage products to try to become platforms. To me, the VC was showing a not-uncommon tendency to swing for the fences (or rather, to suggest that an undiversified startup founder should do so).
I hadn't considered that freshman was compound of "man", but after thinking "how is it different from human" I realized the plural of freshman is not freshmans
> I remember VCs telling me to be a platform, not a product.
VCs incentives may not be aligned with your incentives. They are looking for Unicorns (Decacorns? Centocorns?) and are prepared to have _you_ take on a high risk of failing to improve their 1:100 successful investment upside calculations. You building a comfortable 8 figure revenue and 7 figure profit company over 5 or 10 years is basically a failure in their eyes.
For every Facebook or AWS, there are a 100,000 profitable "product companies" and probably a million successful-enough "lifestyle businesses".
If you want to take on the risk and shoot for the stars, sure - follow that VC advice. If you'd personally be happy with an 8 figure exit or a high six figure salary for as long as you want it, you can reduce your risk of failure substantially by _not_ following that advise to the letter.
This works for video games too. Warcraft 3 had a comprehensive editor and cloud functionality built in which allowed games such as DotA to be made. However, the base Warcraft 3 game is a masterpiece in its own right, which drove users to the platform. If only the editor had been released, it would have never gathered the critical mass for acquiring users.
Those lessons on Azure are fairly generally applicable. A lot of the services seem to be lacking/overkill somehow, in that either a service is too basic to be useful, or it's been needlessly specialised to fit a (probably brief and now outdated) marketing requirement.
27 comments
[ 0.24 ms ] story [ 69.1 ms ] threadOne of the lessons I omitted (because the post was getting a bit long), is we started off as cross-platform (Slack, Teams, and Discord) but in the end we decided to focus on a single product.
In retrospect, we've struggled to decide if that's a lesson to learn. Should we have started with a single platform? It certainly makes it much faster to build for a single platform. But at the time, we really thought the cross-platform chat-ops would be a distinguishing trait!
Anyways, I hope you enjoy the post!
> Balance your early engineering and infrastructure with achieving Product Market Fit
No, not really, you should focus way more on the latter really. We devs love the first tho. e.g. comment from your original post 12mo ago: "Super stoked to see you launching after working on it for so long!" -> how much of the code you've written was necessary to come to the realization you eventually came to? Based on the way you described your trouble selling, seems like very little to none.
- Azure seems like a bad choice (running out of capacity lolwut)
- corollary to above: don't get too attached to where you worked. Seems like your original idea was heavily based on something u saw internally. Just because something works well at one (usually large) company you worked at doesn't mean it serves a widespread market need (I've been burned by this).
Just some thoughts, hopefully your pivot is successful!
You're absolutely right. I think I should have phrased this as "Don't completely neglect your early engineering and infrastructure." Some choices could inhibit our ability to achieve product market fit.
> - Azure seems like a bad choice (running out of capacity lolwut)
I think the pandemic created supply chain problems that affected a lot of companies. There's a lot of reasons to like Azure for me. I'm familiar with it. They focus a lot on developer experience. But this one issue really hit hard and definitely makes me want to be more flexible in how we deploy to the cloud.
> - corollary to above: don't get too attached to where you worked.
Ha! Yeah, we really loved the GitHub way of working. Turns out, GitHub had a unique culture and it doesn't necessarily translate over to whole market. I wish I had included this in the post.
> Just some thoughts, hopefully your pivot is successful!
Much appreciated!
That being said, a good stack that you know well can affect how quickly you build and how quickly you can adapt the product to changing market conditions.
So here's what we use:
- ASP.NET CORE( - Primarily ASP.NET Razor Pages for the web app. ASP.NET MVC Controllers for the internal and external APIs we support.
- C# - We try to stay on the latest version. The recent pattern matching improvements alone make our code so much cleaner.
- [HTMX](https://htmx.org/)\* - for front-end. We're not at the point where we feel we need a heavyweight front-end framework like React. We like the 37signals approach of shipping "HTML over the wire". We're also big on Web Components. That's a result of our [GitHub heritage](https://github.blog/2021-05-04-how-we-use-web-components-at-...).
- TypeScript - for our front-end JS. This is a recent addition. Most of our JS is still ES6.
- Azure Database for PostgreSql - PostgreSql is rock solid and great for storing all kinds of data.
- Azure Functions - we support three types of custom code skills that customers can use to enhance and customize the bot : JavaScript, C#, and Python. We run these in Azure Functions.
- App Insights - We use this for logging.
- Azure Managed Grafana - We have a nice Grafana dashboard based off our App Insights logs that helps us get a birds-eye view of how everything is doing.
- Azure App Configuration - For feature flags.
As you can see, it's pretty heavily Microsoft based. Part of that is my background. The other part is we got a lot of Azure Credits when we joined the [Microsoft for Startups](https://www.microsoft.com/en-us/startups?rtc=1) program. So it made fiscal sense for us to stick with Azure.
I do like that we can manage everything in a single portal. But some of these tools are not best-in-breed as we will be looking at other options down the road.
Wow, Microsoft must have really drowned you with free credits to choose Azure. We also tried Azure 2.5 years ago when my small team (3 founding devs) started with our startup, but after 6 months of constant problems, broken services, outages, and completely out of the blue unexplained service failures we had to give up. We wasted a lot of engineering time on bending our app to Azure's needs and still had issues. We eventually migrated to Google Cloud and hadn't had any problems since then. I am not kidding, the first 6 months we must have spent at least 70% of our time on issues which we wouldn't have had on AWS or Google. Azure really under delivered on all fronts. Things looked extremely promising and then when we used a service we realised that most useful (often necessary) features were behind extremely expensive tiers and then it meant we had to either take huge hits on our hosting costs or build weird workarounds. We didn't want to go against Azure and often chose to pay, but even the higher tiered services then started to act up and often result in totally unexpected behaviour. Good luck to you though!
Good advice. People rarely want a platform, especially from a new entrant. They want an aspirin tablet.
Once they are hooked you can expand.
A sticky platform will be stickier than a sticky product. But that doesn't mean every product should be made into a platform.
Except Facebook started as a product.
FB started by “selling” access to the freshman* picture book. They only became a platform later.
* hopefully a less sexist term is used these days.
They used to just be an app, and now they have an ecosystem of products (Whatsapp, Instagram, etc.). I wasn't referring to the fact that they also run an advertiser-facing platform at all. I was just pointing out that they started as a single product and have expanded to being a larger platform, with all the network effects/benefits that such growth entails. That's great for them, at that stage.
But it doesn't make sense for all earlier stage products to try to become platforms. To me, the VC was showing a not-uncommon tendency to swing for the fences (or rather, to suggest that an undiversified startup founder should do so).
VCs incentives may not be aligned with your incentives. They are looking for Unicorns (Decacorns? Centocorns?) and are prepared to have _you_ take on a high risk of failing to improve their 1:100 successful investment upside calculations. You building a comfortable 8 figure revenue and 7 figure profit company over 5 or 10 years is basically a failure in their eyes.
For every Facebook or AWS, there are a 100,000 profitable "product companies" and probably a million successful-enough "lifestyle businesses".
If you want to take on the risk and shoot for the stars, sure - follow that VC advice. If you'd personally be happy with an 8 figure exit or a high six figure salary for as long as you want it, you can reduce your risk of failure substantially by _not_ following that advise to the letter.