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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> ...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 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.
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.).
> 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.
> 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.
> 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).
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?
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]
> 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.
> 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.
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!
> 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.
> 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.
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 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.
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.
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.
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.
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.
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?
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.