SaaS services behind a startup(bytebase.com)
bytebase.com
SaaS services behind a startup
https://www.bytebase.com/blog/30saas-services-behind-startup
125 comments
There's a big trend of HN voices where people claim design somehow isn't important when in fact design demonstrably drives sales, user acquisition and user satisfaction. IMO design is often the #1 most important thing outside of the product itself, and great design can elevate a mediocre product into something great.
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.
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.
Design is important though every time I work with different designer, there's almost nothing new pattern to me. Nav, grid, list, section, card, info grouping (title here big, subtitle/description here a bit smaller, tone down, thing's status at some corner or after title). Maybe I did so many roles at so many projects and kinda realize this specialized roles doing quite little work or not enough work to be a dedicate role. Fair point for designer role is those exotic marketing and landing pages (lots of images, fancy typography, cool background pattern) .. though they will end up with grid features or zig zag (image/text, left/right).. again.
The software engineer equivalent of this: there is almost no new pattern it is all just for loops, variables, lambdas, if statements, etc.
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.
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.
What's new in backend is business logic. User interfacing logic is not that much. Form POST is a function call with arguments analogy, it doesn't compose well into new function, and barely use return value to compose more.
> there's almost nothing new pattern to me. Nav, grid, list, section, card, info grouping (title here big, subtitle/description here a bit smaller, tone down, thing's status at some corner or after title).
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.
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.
No, not the same. It's entirely different role. UI communicate with user, like buttons, controls on your washing machine, they are supposed to be very easy to use and should repeat pattern shared amongst vendors. Backend logics is business logic, they compose in so many ways, that's why it's "programming language". There's visual programming, but that's not the same as application GUI.
> Maybe it's just because I'm getting old, but this whole "Don't build it yourself, buy it. Focus on your own business, and whenever you need something extra, use a Saas" seems to me like an anti-pattern. I cannot back it up, it's a gut feeling.
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.
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.
Counter argument: if they’re paying designers, why would they not pay for the tools that enable them to be most productive? Figma is a small cost, relatively. Asking them to use a tool that’s worse is like hiring a developer and refusing to pay for a Jetbrains subscription, the tool is worth way more than the pennies saved.
I would hard disagree. Tools like Figma are humongous force multipliers. Using a less useful tool will cost you money. There's an ROI calculation with everything, and they may be overpaying for a few of these, but the list of tools looks pretty on the money to me. Dependency on tools is a risk, but dependency on people is a lot riskier. Institutional knowledge is a bane on maintainability.
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.
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've been building since the 90s too, and I sort of agree with you, but it's a spectrum.
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'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.
> 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.
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 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.
A lot of these companies are not trying to exist long term.
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.
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.
It's familiar scheme. It will do just fine when the mass couldn't resist hype, they will buy to help these early network stop burning cash. Fake it until you make it, while faking it needs a gigantic collective hype.
You don’t think DIY or ‘scrape by without a solution’ represents a significant dependency?
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?
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?
> ...it's a gut feeling...dependencies: why on Earth would I want to build a product with some many dependencies?
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?
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?
The company is paying like $150k/mo in salaries (conservative ballpark based on 20 employees). $1k/mo at that point is a rounding error, and if in total that spend actually does move the needle on productivity in any significant way, its easily worth it.
The parent comment is viewing productivity as dynamic and time varying.
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.
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.
I find large orgs tend to build inhouse tools as they get bigger. But you're never going to get big if you start optimizing for late stage scaling needs before you've even found your market footing.
I worked with a bunch of early stage startups, they don't need to build a lot of features like marketable products. Lots of scripts and poor ui will do just fine with manageable maintenance (devs even like their poor invention .. hope they would opensource it)
> 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 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.).
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.).
> doing your own auth implementations is somewhat risky
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.
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.
> people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own
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.
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.
> 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.
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).
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).
Why in the world do people use SaaS auth?
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.
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.
Well, many reasons, to be honest. Yes, you can easily set up some local LDAP/AD/Whatever and setup some OIDC/SAML connectors.
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?
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?
Sounds like BoxyHQ could be relevant here. Plug-n-play for developers that need to build enterprise features like SSO, audit logs, directory sync, privacy vault and other boring stuff that are required to be compliant.
100% free & self-hosted. It's Open source (Apache-2.0 license) [I am one of the co-founders, sorry for the plug]
100% free & self-hosted. It's Open source (Apache-2.0 license) [I am one of the co-founders, sorry for the plug]
> As you said, there are plenty of local options that you only need to run.
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
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
> I think managed databases are a good analogy here.
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.
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.
Here's a great book I reccomend: "Enterprise Architecture as Strategy" (https://www.amazon.com/Enterprise-Architecture-Strategy-Foun...)
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.
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.
I'd probably be considered old too but all these point services add up to a lot of complexity IMO. I've been running on WordPress for about 10 years and it got unworkable because everything requires a plugin. I finally got off and vented my reasons and delight with an "all in one" platform like Ghost. YMMV of course and we still use things like Zapier but still!
https://ipocandy.substack.com/p/free-at-last-free-at-last
https://ipocandy.substack.com/p/free-at-last-free-at-last
> I've been running on WordPress for about 10 years and it got unworkable because everything requires a plugin
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.
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.
> Maybe it's just because I'm getting old, but this whole "Don't build it yourself, buy it. Focus on your own business, and whenever you need something extra, use a Saas" seems to me like an anti-pattern. I cannot back it up, it's a gut feeling.
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.
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.
I guess it depends on the needs of a business. But any business that has the money to pay $100,000+/yr for a product designer should be able to pay $500/yr for an Enterprise Figma license.
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?
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?
I think there is an important difference between tools/services you need once and those you need continuously.
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.
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.
I agree with this assessment.
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.
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.
> Designer or developer tools are something you only need while you build the product.
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.
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.
Your revenue doesn't immediately stop if you stop incremental improvements. This gives you time to find an alternative tool.
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.
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.
[deleted]
I made the mistake of building too much internally at first vs "outsourcing" it to SaaS. Apart from the initial time to build it, there's all the debt of maintenance after the fact. All of that has a cost and takes away from adding more product value for customers.
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.
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.
>> But I don't think Bytebase needs Figma
(Author here) We definitely need Figma, because we don't have designers and Figma empowers non-designers design.
(Author here) We definitely need Figma, because we don't have designers and Figma empowers non-designers design.
I am in no position to say what works better for Bytebase.
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 :)
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 :)
Not even a designer that can code? Care to explain?
cloud is good to get you up and running. scale as needed and figure out real-word requirements for your infrastructure. the mistake ALL startups make is to stay there and get comfortable. they rather WASTE money than migrate onto their own infrastructure. and it costs them BIG TIME in the long run. but you don't know this until you go through it yourself.
I agree. All of these costs add up and it leads to bad spending habits.
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.
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.
For sure, if time != money
All these examples cost toil in the alt implementation
Know the real value generated per hour of your time, and decide spending accordingly
All these examples cost toil in the alt implementation
Know the real value generated per hour of your time, and decide spending accordingly
It wasn't an anti-pattern years ago, but I have a similar gut feeling today. There's a tendency in this industry for yesterday's best practices to become today or tomorrow's anti-patterns as the market evolves to exploit whatever people think are best practices to turn them upside down and shake.
I share your sentiment. Adopting each of these tools also implies adopting their roadmaps. It's a bet that your needs and their roadmaps align well in the future. Does anyone even look at that anymore when selecting vendors?
This is possibly misleading as this 20-Person company is obviously not yet at a phase where they have a mature customer acquisition pipeline. It's obvious because they're on basic or free tiers for all these services.
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.
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.
Intercom alone will cost more than $1,183 once they roll off the 12 month startup plan.
We migrated to Crisp and are much happier @ $99/month.
We migrated to Crisp and are much happier @ $99/month.
Look at ChatWoot[1] too. It has a an OpenSource[2] self-host option. They claim to be a customer engagement suite, an alternative to Intercom, Zendesk, Salesforce Service Cloud etc. I have no relationship with them.
1. https://www.chatwoot.com/
2. https://github.com/chatwoot/chatwoot
1. https://www.chatwoot.com/
2. https://github.com/chatwoot/chatwoot
especially true on Segment. We're using Posthog so we have an escape hatch.
How do you like Posthog so far? Seems pretty compelling.
It's great. They need to build out more integrations to get to parity with Segment, but I was willing to overlook that for the ability to "escape"
So many tools. What really frustrates me about stuff like this, every new employee brings in their own biases and tools they prefer to work with, then there's a battle over working with an existing process or replacing it for the new shiny thing which isn't really that much better. The majority of time you just spend learning these new tools only to then be replaced by something else. What's worse, every tool is some additional per head user cost. Personally I get the feeling like a bundled GSuite plus some chat and Jira workflow does the job but maybe I'm just old school.
>So many tools.
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.
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.
For what should be a reasonably mature industry, we sure do fuss a lot about how to do things we should probably have solutions for.
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.
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.
> What I actually want is a well designed and integrated solution for 80 to 90% of these functions.
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.
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.
> What I actually want is a well designed and integrated solution for 80 to 90% of these functions.
So, Microsoft Office?
So, Microsoft Office?
Yeah. The one that always gets me is the arguments about task tools Trello vs Jira vs Azure Devops etc.
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.
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.
I agree. I'm not sure how the other fields are, but in the data universe things are going nuts. Too many new tools, algorithms, frameworks, dataviz apps, its crazy. Most of the time, we spent 2-5 days to properly learn some new tool for 1 job and then never look at it again. That's frustrating.
Each tool likely contains a little bit of business logic and domain knowledge too, so you end up spreading your company's procedures and business rules throughout all these little SaaS products.
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.
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.
Well, the same case exists the other way around: Companies using stuff that in theory just """works"""™ that is painful and clearly not the best choice but still using it for lack of knowledge, corporate folklore, someone with ego and power decided it or any combination of the previous.
In the context of it being a 20 person company I don't think what they've listed is excessive. Each person is likely going to be using a subset of those tools in their day to day work.
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.
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.
The question is if that is better or worse than in house tools? If a company uses some analytics tool (knowledge that might be reusable at other jobs) it seems better to pick that up than to learn an in house one (knowledge which will definitely not be reusable).
Based on the title I thought this was going to be an article ridiculing companies with this number of SaaS services.
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.
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.
Author here
>> 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...
>> 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...
You might want to try Appsmith for the internal tools use-cases. It's open source with a big community and a lot of features that are part of the OSS edition that you'd end up paying quite a bit for once your Retool credits run out (I work there).
Also, hear you on Paddle. Fees are quite high, but we found them easier to set up than Stripe.
Also, hear you on Paddle. Fees are quite high, but we found them easier to set up than Stripe.
As a tech veteran, I can only say I'm surprised the list is as short as it is. You don't have a CRM? I think the way a product like Hubspot gets it's mitts into so many startups is because it offers free tiers of a lot of marketing tools (CRM, analytics, email marketing, forms).
We went through HubSpot trial and didn’t convert at the end.
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.
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.
> These PRs must be tiny.
Mostly, for sure https://github.com/bytebase/bytebase/pulls?q=is%3Apr+is%3Acl...
Mostly, for sure https://github.com/bytebase/bytebase/pulls?q=is%3Apr+is%3Acl...
I can explain how that happens. When you're a startup you get hundreds of offers from various places:
- https://mercury.com/perks
- 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.
- https://mercury.com/perks
- 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.
I worked at a 5000 person tech company and it was a mish mash of different services. It may have seemed smart but learning so many different interfeces, literally dozens, was exhausting. When I was at another bigger company with a better devex investment, all of the internal tooling has similar look and feel and felt a lot better.
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.
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.
If you're starting from scratch, I recommend GitLab for hosting your code. They have dozens of extra features you don't have to use, but you will want as you grow. GitHub has only very slowly been adding similar features over time, and while their interface is much nicer, GitLab just has everything baked in from day 1 and has had a much longer head start on getting integration right.
Free tier for a lot of these; if it works for you great, I guess just be ready to need/want to upgrade a bunch, grouped around the same time, at which point this goes up 5x, conservatively
Yeah this is a freemium product’s dream post. Of course these products are all inexpensive because of the free tier, which is the point. Segment, for example, can VERY quickly become a $2000/month expense just by itself when you get any sort of volume. (BTW I love Segment and am a happy user - just pointing out that it gets expensive ;)
Is paying that much for Linear and Grammarly really worth it?
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)
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 don't know how I'd feel if my employer told me to use Grammarly.
I’d be concerned about the security risk caused by their browser plugin, especially given their track record. Grammarly is usually a complete no-go once you have an infosec team.
> I don't know how I'd feel if my employer told me to use Grammarly.
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/
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/
A little dumb, surely.
You should only build software tools that at the right level of abstraction to deliver your product. Building APIs for anything else is a waste of time unless there is a general absence of those tools in the marketplace. If there is or existing tools are overpriced, slow or otherwise untenable, then maybe you should work on tools for that market instead.
Otherwise, after product market fit and as you scale you can go down the abstraction hierarchy to optimize cost of goods sold.
Otherwise, after product market fit and as you scale you can go down the abstraction hierarchy to optimize cost of goods sold.
> 20-Person Startup, 30 SaaS Services
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?
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?
Sounds like an opportunity for a new SaaS product
Look at it another way: if each dependency makes them twice as efficient at each task, they're twice as efficient at everything with fewer people. Doubles efficiency and reduces overhead for a fraction of the cost.
incredible transparency, thank you for sharing!
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?
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?
Yup. That Intercom overlay is always more of an annoyance than a feature. Intercom is immediately -1 for me as a potential customer.
you're probably not the intended audience then. we have a help chat on our page as well. I didn't like it either but we've turned a few tire kickers into buyers pretty quick with it. Helps that we are small and one of my cofounders is ready to jump on it as opposed to a minimum wage employee.
Surely there are config options to make it not so freakin' intrusive for the reader?
just checked and we use hubspot. you actively have to click the chat icon to get the message to pop up
One of the first ublock origin rules i setup is to block intercom chat overlays.
What? That's insane. It's literally an almost immediate portal to talking to an actual human on the other side. All companies may not care about response times but a lot of startups make it a goal to relentlessly cut down on response time to where it's mere minutes.
It's the equivalent of walking in the store and having a sales person show up and ask what you are looking for.
Some people like it, some people hate it. I'm in the latter camp.
Some people like it, some people hate it. I'm in the latter camp.
except that it inconveniences the 99.5% (real number from previous company) of users who dont interact with it, and those that do often get stonewalled into the “it looks like nobody is there right now, please leave your email and we’ll get back to you” flow.
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.
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.
It works well for switched on companies. I've spoken to very small SAAS company CEOs before via it, which is effective. Maybe something to discard over time.
Hating an utter annoyance that expands over whatever I'm trying to do in a cheap and cheesy way that literally everyone I know hates too is "insane"?
Well okay then.
Well okay then.
(Author here) We have done several iterations to make it less annoying, well... As a developer myself, I am not a fan of the popover either.
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.
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.
Actually it depends on the Product you are selling. The more confusing the Product portfolio, the more the consumer needs a chat feature.
Also, a product which is of ancillary type needs persuasion to be sold to consumer where it needs chat feature the most.
If most consumer lands in the page and know what he/she needs, there is obviously no need for such feature.
Looking at their blog it seems more like 1 article per week?
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.
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.
they said in the article it was 3-5, i assume that is aspirational and/or varying and/or has external content included
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
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
He already qualified the articles as being high quality.
(Author here) We publish on both English and Chinese channels. Some articles are only relevant to one Channel. For the general ones, usually, we can’t just write in 1 language and translate it to another. The blog you see only shows English ones, but it also has Chinese ones such as
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.
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.
Thanks for clearing that up :) Is China a big market for you?
Yes, since we are home in Shanghai, China is still an important market for us. Though the Global market is always our primary target.
How do people handle account management with all these damn SaaS, at small-but-big-enough-that-it's-kinda-a-problem companies? Just checklists and a lot of clicking through web UIs?
Asking for a friend.
Asking for a friend.
The answer at 500 or 5000 people is SSO but at thirty people? Yeah. Just hire an admin to help with that kind of stuff.
R&D makes it unclear what development-only looks like, the short description for each doesn't separate category between R and D. I guess it's pretty much 90% overlap.
Interesting.
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.
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.
Interesting to see no sales or CS section in the tools categorization. I see there is an enterprise plan and contact us link though.
1,183 isn't really that bad for a 20 person startup. we spend that much on our cloud and we have 5 people.
Yep, it's around 60 bucks per person per month. Compared to a developer salary of around 6000$/M (in central Europe) it's not even 1% of the salary cost per person. A hand-wavey calculation I know, most developers in the US make more than that, there are additional costs per person and there are not only developers in an organization that size. But All in all, it's not that much...
it's not that easy to hire decent SWE from central/east europe for $6000/month anymore
Hmmm... Then I should consider negotiating a pay raise or switching jobs in the near future
[deleted]
Great to see OSlash as a part of the stack. Thank you Bytebase team
commeny
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.