What stack did you use? On the backend, certain frameworks like Rails/Django can reduce this issue, but certainly for Rails you'll always need a dev around and hopefully the same one who built it. That's very hard to keep.
There's still a lot of chaos on the front end and the favored stack changes every few years. The devs three years from now might not be as familiar with the stack you used. It's honestly a nightmare at the small business level for front end.
As a dev, what's happening now with Zapier, Bubble, Tray.io, etc mirrors what we saw with static sites and Wix, squarespace ten years ago. They are not really at parity for SAAS apps but soon will be and then in a few years they'll be even better. Around 2000 you could easily spend 100,000 on a static website of a quality you can get for free now.
The thing with Bubble etc is that to remain competitive you will likely want to add functionality and anything advanced, anything that really moves the company beyond competitors, will require writing code (or buying an expensive service) and that's ok to add later when you've validated the idea. The downside of this is that's it's so easy to make a SAAS app that your profits are much lower. Apps that could have generated 100k/month are now doing 10k/month and a lot of devs have moved onto different problems like blockchain/defi/etc. We've already had great no code in wordpress for a long time and now it's just moving onto serious SAAS apps.
The new paradigm is definitely going to be Bubble/Zapier/etc plus the code that makes your app profitable added as necessary when necessary.
We ingest a lot of data. We deployed Lambda for queuing, which has helped immensely, but this has caused a lot of other issues elsewhere in the app (something, something schema?)
To create the application we need with Bubble, we absolutely depend on 3rd party integrations, which will require code.
- Stripe
- SendGrid
- Drift / Intercom
Our expectation isn't that there is no-code, it's that there is low-code, and many Bubble dev agencies are actual devs, too.
We will see if Bubble is extendable past $1m ARR or whether we need to re-build the platform.
Cool! I don't understand the exact "schema" issue. Is that your database schema? Having written frameworks for deploying lambda in the past, I can say as recently as 2018 lambda was fairly hard to debug and in general using AWS is difficult for small companies. It's really designed for big business and large organizations where it works really well.
There are some workarounds, for example if your data ingestion is a lot of users uploading excel files, you can just upload from the client side directly to S3 with a pre-signed S3 URL without having to touch lambda. Then you can process the data on S3 using lambda or whatever you want. There are other strategies if you're ingesting real time data.
Yeah, if you're just using plain TypeScript you can certainly re-write crud apps all day and that definitely happens, in fact it's almost certain to happen.
Thanks for sharing. Following along to see how this works for you.
Not having technical leadership in-house has been a pain. We've made it work, but I think things would be a lot easier if there was someone internal who cared as much as we did.
I also know my hiring skills aren't great, even for roles I know better than Senior Dev / VP Eng / CTO and that it's very likely I'll make a bad hire here.
Thanks for the advice on Lambda, I sent this to our dev. :)
But how do they receive the credit card payments? What company is the one that actually receives the credit card payments from the consumer? Is it the "authorized distributors"? Or is the bank account that receives the CC payment linked to the parent company? It seems that states could go after the location that actually receives the credit card payment (if it's not a Caribbean corporation).
I’m pretty sure this is already the case everywhere, but enforcement is impossible unless you already have some other registration requirement (like cars or boats) that lets the state know you’ve acquired something.
That's a great model. Do you use cloudformation each for deployment? If so, have you thought of creating a single cloudformation template for the whole deployment so you can do the entire deployment in one stack update?
Have you encountered any issues to watch out for when only using one APIG for each environment (150 micro-services). Have you encountered any downsides to doing this versus 1 micro-service to 1 APIG? I'm also running into the Gateway throttle limits and I think deploying many micro-services (like you have done) to 1 APIG is the best solution.
We don't use cloudformation because honestly, it sucks. It's hard limits are a pain in the ass to get around (with 150 lambda functions, we need hundreds of resources, so that means nested stacks, which just suck) and it managing the api gateway just doesn't do what we want.
We have a custom script to deploy our own API Gateway using the AWS SDK and we generate a swagger file from simple json config files.
For the API Gateway issues, so far, we have a few things that are something we have to watch out for.
- All lambda endpoints through APIG are lambda proxy type. This means we can have a framework handle standard request / response stuff. The downside is that we can't support binary endpoints easily because they haven't fixed that issue yet.
- HTTP proxy pass through endpoints have to be added to the swagger somehow before we deploy. This is a little annoying, but not a huge issue
- Merge vs Override for deployments. We merge in beta, and override in other environments. This allows us to keep endpoints exactly as they are, but allow flexible testing in beta
1 APIG for 1 micro service isn't great IMO at scale since we run all our endpoints under on domain and mapping all of them would be a pain.
That's very valuable advice. Thank you. I've been following the serverless.com model of 1 APIG to 1 lambda, but that quickly puts you over the AWS limits when trying to manage hundreds or thousands of micro-services.
I agree. The bootcamps have a probably done a great job of flooding the market at the low level. It's pretty clear that bootcamps are the new ITT tech. I think a lot these bootcamps are selling false promises and preying on people trying to better themselves.
Part of the problem is that the cost of therapy, and all medical care, is skyrocketing in the US. We're working on lowering the cost with online therapy. We use a break-fix model where you only pay if we help fix your issues.
Mitt Romney and Donald Trump both have business degrees. I'm not saying I do or do not support them but they are not social science/humanities/liberal arts. Unless you count business as liberal arts.
There's a lot of unsexy dev work out there. Not the kind of change the world startup HN is all about but the kind that made the website for your caterer or hairdresser or an "e-commerce" website for some small business.
Bubbles will continue to grow and collapse, but throughout it all, programming will increasingly become a blue collar job. I mean that both in terms of accessibility to the lower classes, and in terms of social status granted once you've made it into the industry.
This news is just one small sliver of that larger picture.
(And for the record, I welcome this. I just hope the workers get their act together and learn the lessons those other workers had to learn the hard way over the past centuries/decades.)
It is more or less correction, if you are JavaScript ninja (as they call now a days), Islands of excellence like SV, Boston etc would be the places to go, but if you want some javascript competent dev work, in stead of off-shore Appalachia can be a good alternative. There was a near-shore movement, where Software development would be done in low COL/rural areas, I think this one is part of that movement.
There's still a lot of chaos on the front end and the favored stack changes every few years. The devs three years from now might not be as familiar with the stack you used. It's honestly a nightmare at the small business level for front end.
As a dev, what's happening now with Zapier, Bubble, Tray.io, etc mirrors what we saw with static sites and Wix, squarespace ten years ago. They are not really at parity for SAAS apps but soon will be and then in a few years they'll be even better. Around 2000 you could easily spend 100,000 on a static website of a quality you can get for free now.
The thing with Bubble etc is that to remain competitive you will likely want to add functionality and anything advanced, anything that really moves the company beyond competitors, will require writing code (or buying an expensive service) and that's ok to add later when you've validated the idea. The downside of this is that's it's so easy to make a SAAS app that your profits are much lower. Apps that could have generated 100k/month are now doing 10k/month and a lot of devs have moved onto different problems like blockchain/defi/etc. We've already had great no code in wordpress for a long time and now it's just moving onto serious SAAS apps.
The new paradigm is definitely going to be Bubble/Zapier/etc plus the code that makes your app profitable added as necessary when necessary.