Agreed. I posted this comment a few years ago, but it looks like it's relevant as here as well:
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
This is exactly what I do at my SaaS platform. The "Welcome" email explains that you can do the click-here-and-do-yourself approach to onboarding or if you need help or have a question, just reply to the email. I think that's the lowest friction option for most new users. Over the few years that I had this in the welcome email, very few people took advantage of the offer and replied.
A few years ago I attended a SaaS pricing discussion and two of the key insights that emerged were:
* For companies that gated based on usage, free/trial users were much more likely to make the transition to a paying customer. For companies that gated on features, free users tried to find all kind of ways to get things done without paying for the additional functionality.
* In the early days of many companies, most of the features of the product were given away for free, with just a a handful of features gated into premium plans. As companies grew, they realized that many of the features they should have gated, were now free, leaving little incentive for the users to convert.
Thank you for sharing, I think those insights are correct.
We have currently a few features where it's painfully obvious how to cheat the system to gain higher-tier functions. I wont change that, because if you're that strapped for cash that you'd rather cheat than pay 20€, I'm going to look the other way and hope that things change for the better for that person.
lbj, I agree. In my current SaaS app, I have a few customers that consistently try to take advantage of the billing grace behavior to save peanuts by canceling/re-subscribing/canceling/re-subscribing to try to fool billing system. Much as you, I've learned to let that go and hope for a change in behavior in the future.
To try to combat this issue in another app[1] I'm involved in the pricing packages are tiered at 5 SKUs / 200 SKU / Unlimited SKUs. As the customer grow, the driving function of plan upgrades is the volume of SKUs they work with. They also get extra features to better support operating at the higher volume. You don't get high volume features with the 5 SKU plan... We'll see how this approach shakes out.
Very glad to hear that I'm not alone in this line of thought.
Keep us posted on your SKU success. I wont pretend to be a wizard in the area, learning as I go along so stories from other ventures are a big inspiration.
Thanks for the sources, I'll have to check them out. We've recently spent a considerable amount of time tracking, analyzing and evolving our PagerDuty alerting[0], learnings of which we've shared in a blog post.
Shippo is a shipping API company that connects e-commerce businesses and marketplaces to multiple shipping carriers from one place. Our API powers shipping for companies like Shyp and Weebly, and we recently partnered with Stripe to offer shipping directly through their API.
With Shippo, businesses of all sizes can easily access Amazon-quality shipping operations and data. We are doing for shipping what Stripe has done for payments.
You will be faced with challenges in building and scaling mission-critical systems that are used by thousands of customers as a core part of their checkout flow and fulfillment process. From designing robust APIs to turning data sets into shipping recommendation engines, we need a strong and diverse team to help us grow quickly.
Current technical openings include:
* Senior backend engineers - we work with Python (Django), Postgres, AWS
* Senior frontend engineers - we use Ember
* DevOps (not listed yet)
* Support engineer
* Developer evangelist
* Senior product manager
* Content writer (not listed yet)
Technical hiring process:
1. Phone screen
2. Tech interview 1h via skype - pair programming
3. Onsite half day - pair programming/whiteboarding, meet the team/founders
If you're interested in any of these roles, please check out https://goshippo.com/jobs/ or email directly jobs [at] goshippo.com. Please be sure to mention you saw the note on HN.
When you’re a small business, it's important to establish repeatable methods that customers and your support team can follow easily. Do not over complicate. Find the single most efficient and scalable delivery method and perfect it. Start with email based support. Build your reputation as a dependable, knowledgeable and responsive machine through that single channel. You’ll later be able to expand to the other channels but not until you can afford it.
Depending on the size of your business I would suggest some tips from this blog post:
I don't have a story on startup failing due to tech debt, but I do have a story about technical debt forcing us to pass on potentially acquiring a startup.
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand the that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
Heh. I once joined an early stage startup that had a big bowl of spaghetti code, no source control and no framework. My first insistence was source control. Then after a year in which we hired several developers, I insisted we move to a framework so the learning curve wouldn't be so steep for new people.
It was a monumental effort that took more than a year to complete, and we did the "brain transplant" (as we called it) at the same time we were moving to a new data center. Launch was shaky but overall it went very well. One of my fondest memories is of the "war room" on launch day as we triaged incoming bug reports. The team worked great together and at the end of the day we felt like we'd really accomplish something.
Yeah, that reminds me of one of my roles in a company when we were deciding if we wanted to ally with another one. I'd be tasked with spending some time looking at their code base and talking to their technical people to decide if the alliance was technically worth it. Can't remember any of the judgments I made (was a quarter century ago), but my input was an essential part of the decision.
Folks rarely notice how much a decision making matters on this regard and technical knowledge matters a lot on the way. Since having a company* acquired sometimes could be a good business return, but in the first place due to hitting the pedal it has brought lots of technical debt which makes an acquisition impossible.
Just be careful about two things about the Nest protect, which are not obvious when you first purchase it.
1. If your house has the 3rd wire running between all the smoke alarms, so if one detects smoke, they all ring, Protect will not work with that system. It doesn't have the hook up for the 3rd wire. Nest will tell you to replace all the smoke detectors with the protect if you want the alarm to go off in the entire house.
2. If the Nest does detect smoke, it goes off and there is no way to turn it off until it thinks the smoke has cleared. Short of climbing up to the ceiling and ripping it off the power supply it will not turn off. You can't turn off the alarm via the app or by physically pressing the button.
I was originally very excited by the nest protect, but now not so much.
I would love to have a minute to talk to you about this.
I recently took over a new but quickly growing webstore. Just two weeks ago we decided that we want to add "Payments by Amazon" as an option for our customers. We run a Magento Enterprise platform, so I was certain there is an extension for this.
Welcome to the rabbit hole... Do I want Checkout by Amazon or Payments by Amazon? Not clear as advantages of either or why I'd go with one over the other. After spending a few hours reading the differences I gave up and called friends until I got a contact at Amazon payments. Spoke with a super nice rep who explained to me why I shouldn't bother with CBA and look at Payments API instead... "But, I see there is a CBA Magento extension," I protested, can't I drop that in and be on my way? Turns out the extension is maintained by a 3rd party, and as far as I could tell and the rep confirmed it isn't really maintained at all, so even if we spent the money on it, no one could guarantee that it will work.
Fine, let's talk about payments, if Amazon is pushing payments api for merchants, there must be something for Magento users. I get told sorry, maybe there is something in the works but if I want anything up and running for the holiday season, I have to roll my own, and by the way please sign up for another Amazon service (I accidentally signed up for CBA, because it wasn't clear which I service I needed).
So here we are… building our own implementation for Magento. I know it's not Amazon's problem to support how payments are used, but if you want e-commerce merchants to take you up on this offering, some love for the ecosystem will go a long way and some clarity that CBA isn't being promoted anymore.
But I have to give Amazon credit, I've spoken to reps over at Selling on Amazon, FBA, Payments and they are all sharp, knowledgeable and eager to help. I can't say a single bad word about the people that interact with your business customers.
You're the CTO of Amazon, the revenue you're going to get from my business isn't even going to justify a rounding error on the balance sheet, but if you want to hear from the merchants, I'm happy to give you a view from the trenches.
The issue is that when you use Facebook connect and get the user's email it returns the email originally used to sign up for facebook. Since people signed up years ago, many no longer have that as an active address, which leads to the poor email quality.
Wow - I expect most Facebook users have invalid e-mail addresses if that's the case. Originally, you could only sign up with a college or university e-mail address, and pretty much all of those addresses are now dead because people graduated or left.
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.