3 ms·

This is hidden work for running a function SaaS, not launching one. The trick to launching a SaaS is picking the right things to _not do_. Some of the fun of a

by mrkurt 9y ago

This is hidden work for running a function SaaS, not launching one. The trick to launching a SaaS is picking the right things to _not do_. Some of the fun of a SaaS is iterating on everything from product features to pricing to support tooling. It's very difficult to get pricing, trial periods, and billing model right on the first try. So usually you're better off doing less of that, and figuring it out later. And you really don't need a crazy sophisticated drip email setup. Doing email marketing for existing users and new signups right is something that will get you incremental gains. If you convert 5% better when you have 1000 signups per month, you'll be happy. If you convert 5% better when you have 10 signups per month you'll never even know. Silly as it sounds, if you spend more than an hour or two thinking about sales tax before launch, you're wasting time. Screwing up sales tax at launch will not kill you. _Skipping sales tax entirely_ at launch will not kill you. In fact, very little that can go wrong will kill you. You're probably going to die because you didn't make enough go right.

encoderer 9y ago
You beat me to this comment by a minute! I've run engineering teams in SFBA for years and have, with a friend, built Cronitor. I've come to believe the most valuable "soft" skill in an engineer is just a relentless drive to ship, to know how to be both tactical and strategic in avoiding over-engineering. With Cronitor, we call it the JIT Mindset: Don't actually write code until you have to, and focus on solving most impactful problems first. My co-founder wrote more about it here -- https://blog.cronitor.io/the-jit-startup-bb1a13381b0 https://blog.cronitor.io/the-jit-startup-bb1a13381b0 In one sentence it's simply: Over-engineering something can be hard which can trick you into thinking it's real valuable work -- it's not. It's a trap.
- WhiteMonkey 9y ago
  Nice blog post, but just as a heads-up, he never actually defined what "JIT" stands for in the post...
- mooreds 9y ago
  I totally agree. I just today shipped code that lets clients off board, nearly two years after launch. It is really hard as an engineer not to complete a feature, but for a small scrappy saas product that's exactly what you have to do. I liken it to building a bridge while your clients are walking across it. You want to be fair enough ahead that they don't fall in, but not so far you take them the wrong direction or build paths they don't go down.
jamesvandyne 9y ago
author here. I agree with what you're saying in broad terms. And yes, you're right that handling sales tax perfectly at launch won't kill your product. What's the killer is all of the work _surrounding_ that small task. Actually charging sales tax didn't long. More or less if address.region in TAXABLE_REGIONS: subscription.sync() What took the longest was developing and deciding how the screens surrounding will work. Answering things like: - Which fields do we want to capture for an address? - How do we want to store states (or provinces, or prefectures) in a standardized way? - Is there a library that will let me select countries and prefectures? (Answer yes, pycountry is pretty great) - How do I integrate this library into my backend / front end? In my mind it's just fit and finish. Like making the motherboard and inside of the case as beautiful as the outside. If I try and half-ass it or skip it, I'm just going to have to double back and make it right. I do appreciate your final sentence. I'll keep that in mind going forward. :-)
j45 9y ago
It seems making a project into a product is 80% of the work, when factoring in marketing, support, sign up, billing, and all of the other necessary evils, while the initial product can often shrink to 20% of the work during launch. There's also a benefit to integrating as many off the shelf systems to handle the product launch (stripe, paddle, etc), and slowly refactoring the ones away that may be beneficial.

by mrkurt 9y ago

encoderer 9y ago

You beat me to this comment by a minute! I've run engineering teams in SFBA for years and have, with a friend, built Cronitor. I've come to believe the most valuable "soft" skill in an engineer is just a relentless drive to ship, to know how to be both tactical and strategic in avoiding over-engineering. With Cronitor, we call it the JIT Mindset: Don't actually write code until you have to, and focus on solving most impactful problems first. My co-founder wrote more about it here -- https://blog.cronitor.io/the-jit-startup-bb1a13381b0 https://blog.cronitor.io/the-jit-startup-bb1a13381b0 In one sentence it's simply: Over-engineering something can be hard which can trick you into thinking it's real valuable work -- it's not. It's a trap.

WhiteMonkey 9y ago
Nice blog post, but just as a heads-up, he never actually defined what "JIT" stands for in the post...
mooreds 9y ago
I totally agree. I just today shipped code that lets clients off board, nearly two years after launch. It is really hard as an engineer not to complete a feature, but for a small scrappy saas product that's exactly what you have to do. I liken it to building a bridge while your clients are walking across it. You want to be fair enough ahead that they don't fall in, but not so far you take them the wrong direction or build paths they don't go down.

jamesvandyne 9y ago

author here. I agree with what you're saying in broad terms. And yes, you're right that handling sales tax perfectly at launch won't kill your product. What's the killer is all of the work _surrounding_ that small task. Actually charging sales tax didn't long. More or less if address.region in TAXABLE_REGIONS: subscription.sync() What took the longest was developing and deciding how the screens surrounding will work. Answering things like: - Which fields do we want to capture for an address? - How do we want to store states (or provinces, or prefectures) in a standardized way? - Is there a library that will let me select countries and prefectures? (Answer yes, pycountry is pretty great) - How do I integrate this library into my backend / front end? In my mind it's just fit and finish. Like making the motherboard and inside of the case as beautiful as the outside. If I try and half-ass it or skip it, I'm just going to have to double back and make it right. I do appreciate your final sentence. I'll keep that in mind going forward. :-)

j45 9y ago

It seems making a project into a product is 80% of the work, when factoring in marketing, support, sign up, billing, and all of the other necessary evils, while the initial product can often shrink to 20% of the work during launch. There's also a benefit to integrating as many off the shelf systems to handle the product launch (stripe, paddle, etc), and slowly refactoring the ones away that may be beneficial.