SaaS services behind a startup
bytebase.com
bytebase.com
Now, if somehow your people need Figma, you are not going to build it yourself (that would be crazy). But perhaps the question to ask is "Do you actually need Figma?". If your business absolutely depends on how your UI/UX looks and feels, then sure, designers in your company have a powerful voice and, indeed, Figma may be a very valuable tool. But I don't think Bytebase needs Figma. Sure, their designers will probably need to work with prototypes and designs, but the whole thing is not essential to the business imho.
Same goes for Linear, Neat, Sourcegraph, and a few others. And my argument is not, the money ($1K/month should be something any SaaS with decent revenue can easily afford), my argument is dependencies: why on Earth would I want to build a product with some many dependencies?
I don't know. Building a product with so many dependencies feels very amateur, error prone, and prone to instability. Again, it's just a gut feeling from some old dude that has been doing software since the late 90s. Maybe it's just the way things are done nowadays.
I would perhaps look at it from the standpoint—is $XXX/yr going to make my $XXX,XXX/yr employee more at least that much more productive?
If you are a small pre-revenhe startup. instead of using Linear/Atlassian, use Excel.
Instead of Intercom, just have prospects/clients send you an email or fill out a form.
Instead of AWS, use a VPS or dedicated server.
Instead of Hubspot, just hand craft HTML emails and use Amazon SES to send them to your list.
All these examples cost toil in the alt implementation
Know the real value generated per hour of your time, and decide spending accordingly
I wouldn't call it amateur, but picking lots of SaaS tools or solutions is indeed a curious choice!
In some domains, that probably makes sense: you probably don't want to self-host an e-mail server and write your own software for handling mailing lists if you don't want deliverability to be an issue. You might not want to write your own chat solution or alerting solution, when there are off-the-shelf options that are good enough. Furthermore, doing your own auth implementations is somewhat risky, so even if you want to self-host things (though there are many cloud services), you'll probably still be served rather nicely by something like Keycloak. In addition, having your own CI runners or source management system (e.g. GitLab or Gitea) can necessitate certain amounts of maintenance work, as would self-hosting Mattermost/Rocket.Chat instead of just going with Slack and so on...
I guess there are SaaS options for almost every domain and which ones you deem necessary is likely to vary quite a bit! It's probably a matter of striking a balance between the expenses that engineering time for handling development/maintenance/problems yourself would incur, versus just paying someone else to deal with it, as well as who you'd rather hold accountable for any part of your system working.
I'm actually in the early stages of working on a video series about web development, where I self-host almost everything and it does feel like doing a lot of work to get even relatively basic systems online (e.g. no cloud load balancers, no vendor locked managed databases, no cloud monitoring/alerting solutions etc.).
This is a false dichotomy: people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own.
This is not to take away from your points (which I agree with), but for some reason I see many people thinking their only choices are signing their JWTs manually or using Okta.
The problem is there's a trend to prefer hyped-up languages with little/no battle-tested frameworks like those so this is literally not an option for a lot of companies where their "backend" is a pile of hand-rolled shit on top of Express.js, FastAPI or other minimalistic framework.
It might be a technically possible option to switch over to one of those, but too many people would have to lose face (at multiple levels, from individual developers all the way to investors) so it will never happen.
If you want a centralized auth provider across different services, then something like Keycloak is indeed a good choice, which is why I mentioned it: https://www.keycloak.org/ Of course, for the actual services, you should go with a standard OIDC/OAuth2 library, or something like that, even a proven JWT library if need be.
Having Django or Rails (or one of the supporting libraries, like Devise) handle auth and permission control for more self-contained applications is also fine.
I'd just like to caution against writing your own badly documented and badly tested framework for auth, along the lines of storing unsalted MD5 password hashes, or even doing certain controls client side (although I haven't seen this personally, I've definitely seen lacking implementations and have heard stories from others in the industry).
As you said, there are plenty of local options that you only need to run. It also has the largest risk of compromise and data leaking from any service you may use, the largest amount of potential lock-in, and the least need for integration.
If you take any property of a service that makes it a good target for off-shoring, and reverse it, you get auth.
I think managed databases are a good analogy here. While I might run my own PostgreSQL/MariaDB instance, many out there won't be overjoyed at the idea of actually needing to run and manage the damned thing, as well as set up some kind of alerting and handling the need to eventually scale it up, in addition to backups and failover.
> It also has the largest risk of compromise and data leaking from any service you may use...
PII is definitely a big concern, even if something like password hashes aren't too useful on their own (provided that they're salted), though in cases like that it might actually make a lot of sense to utilize a widely used and tested solution that's specialized for this particular use case.
In many cases, thousands of people across the globe will be able to develop something and squash any bugs in it better than you might be able to do individually or with your own team, though there might be a few exceptions out there. Auth is probably not one of the cases where you want to write code without a lot of eyes on it.
> ...the largest amount of potential lock-in...
This is debatable: standards like OAuth2 and OIDC technically make many of the solutions and libraries way more pluggable and make it easier to choose between various implementations, depending on your needs.
Of course, something like Keycloak also has its own API (as do many of the cloud offerings) so if you build too much automation around a particular implementation, then that advantage partially goes out the window.
> ...and the least need for integration.
I'm not sure about this, it probably depends on your architecture. If you have a monolithic web app, then you probably don't need a separate turnkey/SaaS solution, whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.
That said, I'd still opt for self-hostable options whenever possible, albeit I also don't trust cloud based password managers and such, preferring something like KeePass instead. I've probably just come to a different conclusion in regards to usability/responsibility/features/security than some other people.
Sadly, there aren't that many good options out there at the moment, apart from Keycloak. For example, IdentityServer is promising, but went in a commercial direction: https://duendesoftware.com/products/identityserver#pricing
There is at least some work in managing a database. The risks are very similar, but at least there is some value in offshoring it.
I have never seen offshoring it being a net positive in terms of labor saved alone (it's way more work to make sure the managed database stays running than doing it yourself), but it can be positive in theory. It can scale down better in theory too.
> whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.
Well, Keycloak isn't a could SaaS. I bet the clould alternatives will give you all kinds of issues, starting at bad pricing (on that link, you will be enterprise before you can blink). But well, there is no reason at all to go and confirm it, the best they can do is to not add unreasonable operational costs over running your own, and just add some huge risks.
SaaS like Okta, OneLogin, even Google Directory offer many things that you don't have to think about:
- If your organization doesn't use SCIM and you have headcount that requires HR, then your IT department is wasting time. You also probably will fail audit.
- How do you limit which users allowed to use a service that uses OIDC or SAML?
- Where is audit log stored?
- What's your SLA?
- Does it integrate with HR software?
- Does it restrict access based on location? Is there some logic to prevent a user from city X suddenly login from a city 3000 miles away?
- Do you have contractors? How do they access resources they need?
- Service accounts?
100% free & self-hosted. It's Open source (Apache-2.0 license) [I am one of the co-founders, sorry for the plug]
i.e. Productivity may increase in the short term, but may decrease in the long term due to some tooling shortfall.
Whether or not that matters is dependent on a company’s goals and funding strategy.
Sunk cost (amongst other factors) is a gravitational force on orgs that try to get things done without the right tool for the job.
What’s an example of a thriving tech company with home grown UX tooling?
You'd need to treat WP as if it was a Linux installation - you can install ANY package you want, and there are a zillion packages that instantly to be able to do anything, but if you go postal and install a billion packages, you will have to maintain all of them. Even if WP makes it easier thanks to prioritizing backwards compatibility, its still a task.
But there is no comparison - one day you will need to do something, and Ghost/Substack/Whatever won't have the feature for it. Then, back to WordPress.
Designer or developer tools are something you only need while you build the product. If those suddenly go away, the code you've already written with them will continue to work, so while it will slow down future development until you find an alternative, it won't stop your current product from working.
Services that your product depends on to work are a different matter; if you built your service on AWS InfiniDash and it's suddenly deprecated or they hiked the price beyond what you can afford, you are screwed - your existing, currently-working product will stop working.
I don't see much of a problem in using third-party tools for the former but the latter is definitely dangerous and should only be used as a last-resort.
My philosophy as tech lead was this: every time we wanted to start using a SaaS product, up to and including cloud hosting itself, we needed to have a Plan B to migrate to in case the service suddenly went away for any reason.
Eg.: we needed a message queue, we picked up an Azure product because it was the most convenient and covered all our requirements at low cost. But we coded against an interface and we implemented a proof-of-concept RabbitMQ implementation as a backup plan (also came in handy for local testing!). If we had to drop the Azure service for any reason, we knew we could install RabbitMQ on a VM and tune it up to production standards relatively quickly.
What startup isn’t constantly building their product? I’ve never worked at a startup, or any company, where the product was “done”. There is always something to add, something to fix, or something to improve.
On the other hand, if the infrastructure your product is based on stops, your product is dead, revenue will stop and you may even breach your SLAs and have to pay them compensation.
As you think about your organizations business processes, and capabilities (note capabilities are distinct from tools, I don't think programmers think about this a lot, but it's important) there are trade offs depending on your business model. The book gives a solid foundation on the trade offs of integrating systems, and not integrating systems. It was written before the modern age of SaaS, and it comes from the perspective of a large enterprise, but the concepts are easily transferrable, and I think you can take some of the ideas and apply it to any company trying to make a build/buy decision.
Nope, its legit: Majority of startups don't have the resources building themselves. They can, but every dollar spent on that and not the product ends up being a risk.\
The objective of a startup is to get to a stable and strong position as fast as possible. And this can only happen with its product/business. The 'great infra' that it may have behind is totally transparent and, honestly, irrelevant as far as the end users and customers are concerned. We, as technical people, love to think that if the infra or the software breaks, it will affect the business too. But it will rarely break, with any competent people handling it behind the scenes. Be it in-house, be it SaaS.
Its MUCH better to get to a point where the product/business is actually making money and the company has the funds and deal with everything later. Because without a viable business, it won't matter how great your infra or software stack is.
(Author here) We definitely need Figma, because we don't have designers and Figma empowers non-designers design.
Everyone has their own workflow and you pick tools that match you people and make them effective and productive.
Sounds like Figma is just the right tool for your team.
We opted for Vue components with Tailwind and built "design system" with Vue components.
That worked for us :)
They are trying to be sexy enough to be bought in the near future.
Using a bunch of tools like these make them part of the pack.
The investors and founders of all these tools now know about this company and know that they are "in".
So it is more of a peacocking manoeuvre than an actual genuine need.
This is why a lot of startups are not really helping make the world a better place.
This company's product for example is also targetted towards other startups.
It's all a big house of cards at this point.
Their monthly Figma bill is $15. If you saw how gutted people were by the adobe figma acquisition, you might be able to infer how great of a tool it is and how much productivity people get from it. There's no way not paying for it is a good idea.
You could say the same thing about codebases, ie whenever I work on a new full stack project, there's nothing new, a nav, grid, list component that I fill in with props.
There are many different kind of designers but they operate at a higher-level. For example: observing users, creating user flows, creating site maps, creating designs, validating designs, gathering feedback, etc.
I find most engineers are terrible at doing the above, and I include myself in this. If I was running a startup I would invest a lot into finding a good designer and making sure they have a productive environment.
That being said, what I think you may be getting at is not so much the reliance on tools but the loss of ownership of your own data and your platform. That's a real thing I would worry about, but I don't think anything in this stack runs that risk. If you have locked yourself into a way of doing things or bought into a closed platform that hogs your data or your relationship with users (ie Apple App Store, Youtube, Patreon) then you're definitely tying a lead weight to your business. But everything on their list is stuff you can easily migrate off of when you outgrow them.
I'll start at the top, at the enterprise level. At that level it makes sense to bias towards buying instead of building for anything that you can buy cheaper than build+maintain, because there is no reason to distract yourself from where your business adds value. Lock-in isn't really a concern, because when you get big enough, their competitors will bend over backwards to help you solve that problem.
You don't even have to be that big -- at one point Azure offered to provide full time engineers to help reddit move from AWS and that was many years ago when reddit was a lot smaller.
At the earliest stages, it makes sense to use all the SaaS products. You don't have the time and resources to build it, but they all have cheap or free tiers, so you can afford to buy it. Lock in isn't a huge concern because your data is small enough that even manually moving it isn't that big a deal.
In the SMB range is where it gets hardest -- on the one hand you may not have resources to buy because you're beyond the free tier, but you may also not have the resources to build and you may be worried about data lock in. Hopefully by the time you get to this stage, you can predict which parts of the business will become critical and which are nice to have, and start transitioning off of the SaaS products for critical products that make sense to build in house.
I know HN dislikes sales folks (me, too), but they're often a decent, relatively quick gateway to getting a fair amount of work of this sort done for free, if it's part of getting you onto some kind of recurring billing situation and you have more than a paltry amount of money on the table. Like, you don't have to be a fortune 500 to get this kind of service.
Providers that suck at this also usually have trash support, when you eventually need to use it, so asking for this kind of high-touch onboarding assistance up-front even if you don't strictly need it can also help sort wheat from chaff.
I now start with SaaS, and if something becomes strategically important or the costs skyrocket, only then consider an alternative such as building internally or a partnership.
The truth is, your code, the entire discipline of software engineering, everything humans do, and in fact the entire universe itself, is built on dependencies. It's how the world works. We stack more and more layers of abstraction, to achieve higher and higher leverage.
Your employees are dependencies. The internet is a dependency. The building you work from is a dependency. Heating and electricity are dependencies. Food is a dependency. Your fellow man's willingness to pay taxes to fund a common defense (government) is a dependency. Your health is a dependency. The earth is a dependency. Etc. Etc.
Acknowledging the fragility of existence makes us uncomfortable. However, I don't think the right approach to deal with these feelings is to do the business equivalent of running off to the wilderness and living alone in paranoid self-sufficiency.
If you're willing to spend $15,000 a month to depend on a fragile human "employee" being around, maybe paying $15/month for Figma isn't such a big risk--and is in fact worth it?
A lot of this now is also about supporting others within your community. I'm sure you do this with code, support junior developers? Now we're in an era where you can do the very same, but for those creating products, too.
> I don't know. Building a product with so many dependencies feels very amateur, error prone, and prone to instability.
I bet if most were honest, and reviewed their code dependencies (external libraries) you could make the exact same statement.
> Again, it's just a gut feeling from some old dude that has been doing software since the late 90s. Maybe it's just the way things are done nowadays.
It's just an extension of doing what you're most likely already doing, and firmly believe in.
As soon as they try to land a customer with any sort of compliance requirements, the pricing tiers on nearly all these SaaS plans will jump significantly. It's unrealistic to expect to pay less than one full time employee for basically all your supporting infrastructure.
SaaS is definitely great to start out, as demonstrated here, but the danger is lock-in and expense creep, which can kill otherwise strong companies. Burn cash to accelerate but always have an escape hatch ready for when you need to tighten the purse strings.
We migrated to Crisp and are much happier @ $99/month.
They pretty much all do the same thing but there will always be someone who picks one specific feature of one specific tools like its the deal-winner even though they could easily live without it.
As for marketing tools, don't get me started, a lot of them I find morally unpleasant (well, the ones that provide leads for a fee, which are mostly obtained indirectly without consent or knowledge)
I think lots of people think that if there is a tool, they must use it instead of Excel/OpenOffice whatever at $30/person/month just because it is a bit nicer.
Which is why, despite HN / Social Media or literally everyone working in Tech thinks we need decentralise or more tools for each function. What I actually want is a well designed and integrated solution for 80 to 90% of these functions.
> but maybe I'm just old school.
The whole tech industry is hype driven and worst than fast fashion.
I spend a decent amount of time split between different projects, old and new, and there is something very nice about a well-appointed mature framework that you don't get from cutting-edge bare-bones approaches.
So, Microsoft Office?
I agree. I think a lot of this should just be done by one tool. Unfortunately the incumbents like Google and Microsoft are doing a poor job beyond the initial software they built e.g Google Cloud Dashboard takes 5 seconds between page loads, this is horrendous. To be honest I think if you scrapped a lot of the UI functionality and made it CLI based it would work far better. If all SaaS tools were reimagined as a singular CLI tool, maybe even in a UI, it would be better than what we have.
On one hand you have savvy non-technical people running entire businesses from a complex spreadsheet, and I think the SaaS Rube Goldberg is what you have in the other hand.
Just spit balling, but say they had 2 designers who spent most of their day in Excalidraw/Figma/Retool. For them that's a great investment as it makes their lives way easier. Same deal with developers and github/sourcegraph/... and marketing with intercom/mailchimp/...
No doubt they could consolidate some things and just completely do without others, but overall it doesn't seem that crazy.
It feels like they're really stretching the number of tools they're using for this article. I find it hard to believe they're actually using all these tools on a regular basis.
Excalidraw (???), multiple analytics tools, multiple hosting providers, Cloudflare, Algolia (Their docs appear to be using Docusaurus which comes with Algolia out of the box, so ???), multiple messaging tools, +more.
> The R&D team of just over 10 members releases a new version every two weeks, and each version has 100 to 150 PRs submitted.
Uhh, what?
2w = 10d
100 / 10 = 10
The team is putting up a minimum of 10 PRs a day? How do they have time to put up so many PRs and then also review other people's? These PRs must be tiny.
Mostly, for sure https://github.com/bytebase/bytebase/pulls?q=is%3Apr+is%3Acl...
>> I find it hard to believe they're actually using all these tools on a regular basis.
We do rely on all mentioned tools, though for some tools, we only use them occasionally due to their nature (e.g. we don't need to visit Pulley every day to manage equities).
>> Excalidraw (???)
Oh, Excalidraw Plus
>> Their docs appear to be using Docusaurus which comes with Algolia out of the box, so ???
The Algolia part is correct, while we are Vue based, so we built our own and also implement some special markdown syntax to facilitate tech writing https://www.bytebase.com/docs/document-write-guide
>> The R&D team of just over 10 members releases a new version every two weeks, and each version has 100 to 150 PRs submitted.
It's an open source project https://github.com/bytebase/bytebase. And most are small PRs. Here is our review guide line: https://github.com/bytebase/bytebase/blob/main/docs/code-rev...
1. We don't have a sales team. 2. Our content is all markdown based and stored in Git, so we can't use their CMS and analytics.
We end up managing CMS in a table.
Also, hear you on Paddle. Fees are quite high, but we found them easier to set up than Stripe.
- Stripe Atlas has the same
- Often service you open as a perk from one service has a bunch of other services as a perk
My company currently has a decent credit on multiple cloud providers that I have to use, or it will burn in 20 months.
When you’re a startup I understand you can’t invest in devex but there is a point where investing in your own tools makes a huge difference to internal productivity.
While $1183 is already cool, I think it can easily go sub-1000 (not really important though as SaaS expenses are negligible compared to many other expenses)
I mean, everyone makes mistakes, or words things in ways that can get a bit long winded etc. I don't think it's that much different from having spell checking on in your word processor or browser. Seems like a nice tool.
On a related note, Hemingway seems nice as well: https://hemingwayapp.com/
Otherwise, after product market fit and as you scale you can go down the abstraction hierarchy to optimize cost of goods sold.
The way I look at it is that's 1.5 external dependencies per person. How do they even remember what they're using, never mind pay for it?
paying $70 for intercom but $20 for mailchimp. interruption marketing vs permission marketing. when i first land on your page the fake intercom chat is the first thing to put me off, i gotta ask if you think its actually worth it?
last question on the content productivity. 3-5 articles per week is very good. what kind of traffic does that get you, and have you considered “slow down to get 10x results” type experiments?
we all understand the premise but this form factor has in practice failed to deliver. instead if people want instant response they tend to join the public slack or discord. you know, the apps actually built for community chat.
Some people like it, some people hate it. I'm in the latter camp.
Well okay then.
Imo from a content perspective if you have high quality content ready you should publish 10 articles per week - as long as your crawl budget is fine (which most of the time it is) - the more the better.
is 10 articles a week actually desirable? do we care about quantity of output or quality (measured by traffic, conversions, or vague “brand reputation”)? sometimes going away for a month and writing one good skyscraper article (seo lingo) is worth 100 tiny little forgettable things
https://www.bytebase.com/zh/blog/database-review-2021-byteba...
We don’t list them on the blog front page because most Chinese audiences consume the content on WeChat.
While wearing the marketing hat, I would say intercom is useful to some extent. We probably won't have those customer conversations if we don't have that small bubble.
We are building a dev tool for database development workflow, which is not a big market. We are also based in Shanghai, thus unlike valley-based shops, we don't have many viable ways to engage (like private introduction, offline meetup).
Internally, we also struggle between the experience and the leads, and as this topic is raised up here again, it will surely bring up another round of team debate this week.
Asking for a friend.
We use just a handful of SaaS services and are very happy.
Rather than adding services and increasing surface of failure/attack we focus on picking good partners.