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.
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
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.
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.
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. :-)
Yes, these are the "features" that really bog down the excitement when trying to launch -- user invites, user profiles, billing, transactional emails, password reset, file upload, PDF conversion, free trial capability, coupon code capability, shared accounts, PERMISSIONS, etc. Then you get to the next level -- search, caching, deploying.
Not exactly in the same vein as the others, but I've never seen soft-deletes done really well either i.e. the user can "delete" something but it still lives in the database. It's one of those features that sounds good but when it comes time to implement, it ends up being more trouble than it's worth.
Another point I didn't see mentioned was "support and documentation" (not necessarily SaaS specific, but still applicable)
I was the lead developer of a greenfield new b2b web application that took several months to develop the MVP for, then another almost 2 years to develop support tooling and systems for.
We would get calls that it didn't work with no other information, calls that it didn't work with "my older samsung", emails with pictures taken with another phone of the login screen with no other information, users that didn't know the name of the company they worked for, or even their username in the application.
We found suprisingly that there was a subset of our users that couldn't even tell you if they were on iOS or android! But quickly we learned that it's not their job to care about that, it's ours. We spent the next almost 2 years writing in debugging code, shipping logs back to our servers, writing code to send errors back to us to avoid having to ask the user on the phone to "please read out exactly what the error message says" only to find out that it happened to them last week and they don't remember... We wrote code to be able to "playback" what a user is doing in the app before they have a problem so we could identify UX issues, and redesigned UIs to include important information so when users sent us screenshots or pictures of the device we could get useful information from it from anywhere in the app (like app version, os version, username, company, etc...). We wrote documentation for how to enable camera permissions that they may have inadvertently denied for several android versions and flavors and iOS versions because we found that some users would be confused if the images and names were slightly different.
If you asked me today what makes our app better than all of our competitors, i'll tell you that it's hands down the "support" capability of the application, and that if a user has a problem, we can track down what they were doing when it happened and figure out a fix (either procedural or technical) sometimes before they even call the problem in!
Also, it's a sure fire way to deflate the ego of the hotshot lead developer that thinks he's made the best thing since sliced bread when the most important part of the application is a glorified log shipper!
Soft-deletes are highly expensive technical debt until properly wrapped with an API. Until that happens, every developer/consumer needs to remember to check for archived=false.
One solution I’ve sometimes used is to move deleted records into a separate NoSQL database at delete-time. Keeps data around if you want to implement “see trashed/archived” later, can be migrated back in under an archived flag once you have that API, but in the meantime everyone else (including, crucially, the analytics team) can pretend that everything in the database is live. A kludge, to be sure, but sometimes a necessary one.
We actually have soft delete in Kwoosh. We’re using Django on the backend. The way we went about implementing it was with a flag on our core data-type (Apps, Screens, Discussions, Tasks etc... all share a common parent class). Then we used an custom Manager class (Django’s name for the bit that lets you set default filters for models) that sets the default filter to only show active items.
If we want to query all objects including archived items (like for viewing them as read-only) we just change our code from Task.objects.filter() to Task.all_objects.filter().
We also have another flag for controlling visibility directly. This makes it manageable to remove a parent task, hide the children tasks, and restore into the expected states.
I should write a more in depth post on this for workshop. Maybe someone would find it helpful.
soft delete aka flag delete is a very common thing in databases.
If it's a customer account that is being deleted then just set a flag on the record or change the user's status. The last thing you want is to try to resolve a dispute where all the details have been removed from a database.
I usually use a date as a soft delete. If it's non-null, its deleted, and, you get to record the actual date of deletion.
I've never found it to be a problem. In fact, I find it's more of a problem to physically delete. You just have to design that way from the get go. Not added on after you've realized ppl leave.
This is why I always scratch my head when I hear about early stage startups say "Oh, yeah, we built our MVP and put it out there and got thousands of sign ups, then we started figuring out how to build a billing system to handle subscriptions..."
I call total BS on that. Trying to shoehorn even something like Stripe into an app that has existing tables for users and companies, and ensuring it WORKS (including handling webhooks for payment confirmation, invoice generation, failed payments etc.) in less than 3 or 4 weeks is setting your developers (and accounts department) up for failure.
If you are selling an enterprise level SaaS, then things like billing history, generation of invoices for your customer's accounts department, handling lapsed subscriptions gracefully, handling changing of credit card details, giving the option of purchase orders or using other forms of payment etc. ALL have to be factored in and built before you even sign up your first customer. (Yep, we even lost a customer during the trial once because we didn't have the ability to generate a PDF invoice for them 'in app').
I set up the payment page of my app in under a day with Stripe Elements and just didn't worry about invoices. If someone needs them I just send them thru the Stripe UI. I have been getting more requests for them recently, but I think it's going to be a while before it's worth building myself.
To counter; we did the billing system after, when we needed it. In fact, the first Saas sale, my business partner phoned up excitedly and said, "I've just sold a licence! Any chance you could hack together a page to securely take this guys details through Stripe", which is just what we did.
We winged it for quite a while with that. It was only after the billing side started to take too much time that we needed to switch to Chargebee to take away all the pain. Sure, it's manual work doing the invoices etc through Xero, but it's not impossible. It's pretty manual with enterprise customers anyway as the billing process is going to involve a bunch of back and forth with purchase orders etc.
I setup Stripe using their API not the Checkout widget and it only took a weekend including receipts. Yes, there's a long tail of work needed for cancellations, refunds, non-credit card providers, multiple subscription plans, multiple billing periods, automated periodic auditing, etc. However, I totally believe a lot of devs can setup stripe in their MVP in a day especially if they only use Checkout and Webhook Events.
"I’ve built and sold software for the Mac and iOS. Those products all had simple billing systems. But with a SaaS, you need to handle all of that yourself. You need to handle payments, and invoices and everything inbetween."
Edit - both Spark (Laravel) and Bullet Train (Rails) will help with a bunch of this stuff:
Thanks for updating with these SaaS providers. We are on the Microsoft stack and have been using AspNet Zero[1]. It would be interesting to see a more comprehensive list on here of SaaS providers and which languages they are built-on.
And now, if you're marketing or selling to people in the European Union, you're expected to have a deep understanding of data privacy law to negotiate GDPR, ePrivacy, and a host of other (often contradictory) regulations.
I'll be honest, I've been selling EU wide for a while now (~2 years), only abiding by UK laws for the LTD, and before that with a Belgian BVBA. There's all the laws which I never thought about, and no one ever said anything about it. Sure, it's not sustainable long term, but now I can fix all of it because I actually have a profit.
So, you can either be afraid and dump a lot of your money into "doing everything right" or start right away and fix shit later. I'd say don't be discouraged by the seemingly spooky EU laws.
I actually think it's in most cases not that bad for new projects, since you can from the beginning design it accordingly. Tracking down all the details, making sure existing vendors are compliant (and having to swap out those that don't) and finding replacements for processes you maybe wouldn't do like that now in an existing application sounds harder than minimizing exposure in the first place. keyword "privacy-first design"
In my experience, billing/invoicing/payments integration is the easy part of launching a SaaS. It's just code, and most of the work is already done for you in the form of libraries. Getting your product 'out there' and getting people to sign up, THAT is the hidden work if you ask me.
"focus on my product"? where do you draw the line around what is your product and what isn't? if you exclude everything around it, the actual nucleus of your product had better be pretty damn amazing to standout from all the other people with an idea.
This is not hidden work. These are decisions. In theory every part of an offering could be 3rd partied, but they will all want to be paid. at some point you have to write something yourself either so you don't have to pay someone or to do it better than what everyone else is using.
having said all of that, chargebee is pretty awesome.
> You need to handle payments, and invoices and everything inbetween
Back to July 2017, when we launched PixLab[1], we opted for Paddle[2] since implementing billing, invoices, purchase orders, refunds, etc. was the last thing we want to code from scratch. We were a small team of C/C++ engineers and ML scientists with no clue on billings.
Not only Paddle did handle all the payment stack smoothly, they do also offer Paypal in the same payment modal which was a great boost for our sales since most Europeans customers prefer to use that method. One drawback is that they took 5% for each sale/subscription instead of the 2.9% that Stripe takes.
I can second the recommendation for paddle. I use it for https://presskithero.com, which has customers around the world, and we are a german company, so we have to handle very complicated european vat rules...which paddle does for us!!
I second this, we use Paddle on https://gimmeproxy.com . It's really nice they handle VAT automatically on your behalf (EU VAT law for online is complicated) and setup was pretty easy.
This kind of thing is top of my list when I think about how little enthusiasm I have for taking our current on-premise, installed enterprise software, and trying to turn it into a SaaS. As a small company, we've barely got the horses to handle the much-lower levels of complexity involved in building and supporting a mostly monolithic application, where we can offload all of the ops and deployment and first-line support duties to our customer, once they've got it installed and running.
I just start checking out when the idea of creating a cloud-hosted, multi-tenant version of our product is raised. Scale, security, liability for data protection, 24/7 operations support, billing, and metrics for billing, all this stuff we don't currently worry much, if at all about, would become first-class concerns. Unfortunately some people seem to think you just wave your cloud wand at things, and poof! everything is magical.
You could half-ass it like many (most?) vendors seem to do. You can always tell they've shoehorned their on-prem product into a SaaS offering when they ask you to port forward on your firewall to your LDAP server and don't support SAML/OAuth/OIDC. Bonus points when they can't give you a dedicated per-costumer IP or range to whitelist. More bonus points if they can't give you any to whitelist at all without a bunch of internal communication/work (shared or not).
We (SaaS, https://geocoder.opencagedata.com/) use https://quaderno.io/ plus their Stripe connector which handles inter-european VAT well. It takes care of invoice PDF generation, UI for users to change their billing details, list of past invoices etc.
These are exactly the pain points that Taylor Otwell (creator of Laravel, a PHP framework) tried to solve with Spark (https://spark.laravel.com/).
It was actually just updated to v6.0 yesterday so it's definitely a good time for considering it.
I personally used it for a couple of projects and I'm really happy about it. It probably saved me a few weeks or a couple of months of tedious work!
These "features" are the whole reason you're building the app--so you can collect money (I assume). At my current company, we've spent the last four months rewriting just this part (moving to a different processor) and we're still not done. Our product lineup is not even very complicated, but working with payment processors is quite hellish. Considering this is the most important part of the application, this should always be considered ahead of time and plenty of time budgeted for it. There's no way you can try to speed this up and still implement it properly.
Seems like a this could be a SaaS all by itself, like the backend of Stripe or something. You build the UI and this thing plugs right into it does all the nitty-gritty.
The biggest challenge for us was a bunch of small tasks that we HAD to do. It was driving us nuts until we realized we could either find a service, make it dead simple (MVP style) or just not do it until we absolutely needed to do it. We worked on being customer obsessed with the absolute list. We ended up with a great product. I can't take full credit, took a lot of advice from great blogs and Lean Startup (the summary is better if you don't have the time. http://amzn.to/2H8isRI).
This is exactly right and largely why I have not launched any subscription webapp on my own (b2c, b2b). I haven't yet invested enough time for an adequately starter backend infrastructure.
I should look into Laravel Spark tho', I hadn't heard of it before and it looks like it might be just what I need.
I'm using Laravel Spark for the SaaS I'm building. It's fantastic, I highly recommend it. The one caveat is that if you're doing some odd billing scheme (e.g. aside from just one or more tiers at set prices), it might take a little extra work.
These SaaS stories are scaring me a little. Is there a non-BS guide that addresses these “hidden” issues associated with billing, tax etc?
I want to build a website with a paywall, accessible with annual subscription only. Let’s assume around 5,000 users for the first year. I assume that I can put together a WordPress website with a bunch of payment plugins - sign up, add cart, PayPal, debit card etc - would be enough.
I used Laravel Spark for telointerview.com,
I coded the base app in React so I use iframes for the spark pages. Couldn't recommend it enough, just dont be afraid to edit the vue files.
There are lots of companies offer "bridge" kind of service between Payment Facilitators like Stripe and SaaS app.
Since all my products are #1 in their niche and I know how dirty businesses especially competitors can play, I do not use any of these bridge services!
There are concerns that these services might sell your customers' data to interested parties or at least roll their own with some insight into your pricing and market dynamics.
We started off using WHMCS. Lots of my friends who rolled their own SaaS got stuck for months changing payment gateways but we just enabled/disabled plugins a few click and kept sailing.
Customers love that we use proven/cheap solution to solve this problem and focus entirely on our app.
[+] [-] mrkurt|8 years ago|reply
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|8 years ago|reply
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
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.
[+] [-] j45|8 years ago|reply
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.
[+] [-] jamesvandyne|8 years ago|reply
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. :-)
[+] [-] dalfonso|8 years ago|reply
Not exactly in the same vein as the others, but I've never seen soft-deletes done really well either i.e. the user can "delete" something but it still lives in the database. It's one of those features that sounds good but when it comes time to implement, it ends up being more trouble than it's worth.
[+] [-] Klathmon|8 years ago|reply
I was the lead developer of a greenfield new b2b web application that took several months to develop the MVP for, then another almost 2 years to develop support tooling and systems for.
We would get calls that it didn't work with no other information, calls that it didn't work with "my older samsung", emails with pictures taken with another phone of the login screen with no other information, users that didn't know the name of the company they worked for, or even their username in the application.
We found suprisingly that there was a subset of our users that couldn't even tell you if they were on iOS or android! But quickly we learned that it's not their job to care about that, it's ours. We spent the next almost 2 years writing in debugging code, shipping logs back to our servers, writing code to send errors back to us to avoid having to ask the user on the phone to "please read out exactly what the error message says" only to find out that it happened to them last week and they don't remember... We wrote code to be able to "playback" what a user is doing in the app before they have a problem so we could identify UX issues, and redesigned UIs to include important information so when users sent us screenshots or pictures of the device we could get useful information from it from anywhere in the app (like app version, os version, username, company, etc...). We wrote documentation for how to enable camera permissions that they may have inadvertently denied for several android versions and flavors and iOS versions because we found that some users would be confused if the images and names were slightly different.
If you asked me today what makes our app better than all of our competitors, i'll tell you that it's hands down the "support" capability of the application, and that if a user has a problem, we can track down what they were doing when it happened and figure out a fix (either procedural or technical) sometimes before they even call the problem in!
Also, it's a sure fire way to deflate the ego of the hotshot lead developer that thinks he's made the best thing since sliced bread when the most important part of the application is a glorified log shipper!
[+] [-] btown|8 years ago|reply
One solution I’ve sometimes used is to move deleted records into a separate NoSQL database at delete-time. Keeps data around if you want to implement “see trashed/archived” later, can be migrated back in under an archived flag once you have that API, but in the meantime everyone else (including, crucially, the analytics team) can pretend that everything in the database is live. A kludge, to be sure, but sometimes a necessary one.
[+] [-] jamesvandyne|8 years ago|reply
We actually have soft delete in Kwoosh. We’re using Django on the backend. The way we went about implementing it was with a flag on our core data-type (Apps, Screens, Discussions, Tasks etc... all share a common parent class). Then we used an custom Manager class (Django’s name for the bit that lets you set default filters for models) that sets the default filter to only show active items.
If we want to query all objects including archived items (like for viewing them as read-only) we just change our code from Task.objects.filter() to Task.all_objects.filter().
We also have another flag for controlling visibility directly. This makes it manageable to remove a parent task, hide the children tasks, and restore into the expected states.
I should write a more in depth post on this for workshop. Maybe someone would find it helpful.
[+] [-] sbov|8 years ago|reply
If you can get away with it, its much better to just delete it out, perhaps moving it into some archive table incase you change your mind later.
[+] [-] jimjimjim|8 years ago|reply
safety first. record everything.
[+] [-] bungie4|8 years ago|reply
I've never found it to be a problem. In fact, I find it's more of a problem to physically delete. You just have to design that way from the get go. Not added on after you've realized ppl leave.
[+] [-] wolco|8 years ago|reply
[+] [-] xstartup|8 years ago|reply
Not needed
-> transactional emails
Most transaction email services offer same old SMTP interface.
[+] [-] cyberferret|8 years ago|reply
I call total BS on that. Trying to shoehorn even something like Stripe into an app that has existing tables for users and companies, and ensuring it WORKS (including handling webhooks for payment confirmation, invoice generation, failed payments etc.) in less than 3 or 4 weeks is setting your developers (and accounts department) up for failure.
If you are selling an enterprise level SaaS, then things like billing history, generation of invoices for your customer's accounts department, handling lapsed subscriptions gracefully, handling changing of credit card details, giving the option of purchase orders or using other forms of payment etc. ALL have to be factored in and built before you even sign up your first customer. (Yep, we even lost a customer during the trial once because we didn't have the ability to generate a PDF invoice for them 'in app').
[+] [-] mritchie712|8 years ago|reply
[+] [-] aidos|8 years ago|reply
We winged it for quite a while with that. It was only after the billing side started to take too much time that we needed to switch to Chargebee to take away all the pain. Sure, it's manual work doing the invoices etc through Xero, but it's not impossible. It's pretty manual with enterprise customers anyway as the billing process is going to involve a bunch of back and forth with purchase orders etc.
[+] [-] welder|8 years ago|reply
[+] [-] mijustin|8 years ago|reply
"I’ve built and sold software for the Mac and iOS. Those products all had simple billing systems. But with a SaaS, you need to handle all of that yourself. You need to handle payments, and invoices and everything inbetween."
Edit - both Spark (Laravel) and Bullet Train (Rails) will help with a bunch of this stuff:
https://spark.laravel.com/
https://bullettrain.co/
[+] [-] wgerard|8 years ago|reply
Isn't this pretty much why companies like Stripe exist?
[+] [-] hbcondo714|8 years ago|reply
[1] https://aspnetzero.com/
[+] [-] rkuykendall-com|8 years ago|reply
[+] [-] slig|8 years ago|reply
[+] [-] robgurley|8 years ago|reply
[+] [-] jotm|8 years ago|reply
So, you can either be afraid and dump a lot of your money into "doing everything right" or start right away and fix shit later. I'd say don't be discouraged by the seemingly spooky EU laws.
[+] [-] forgotmysn|8 years ago|reply
[+] [-] detaro|8 years ago|reply
[+] [-] LeonM|8 years ago|reply
[+] [-] jimjimjim|8 years ago|reply
This is not hidden work. These are decisions. In theory every part of an offering could be 3rd partied, but they will all want to be paid. at some point you have to write something yourself either so you don't have to pay someone or to do it better than what everyone else is using.
having said all of that, chargebee is pretty awesome.
[+] [-] symisc_devel|8 years ago|reply
Back to July 2017, when we launched PixLab[1], we opted for Paddle[2] since implementing billing, invoices, purchase orders, refunds, etc. was the last thing we want to code from scratch. We were a small team of C/C++ engineers and ML scientists with no clue on billings.
Not only Paddle did handle all the payment stack smoothly, they do also offer Paypal in the same payment modal which was a great boost for our sales since most Europeans customers prefer to use that method. One drawback is that they took 5% for each sale/subscription instead of the 2.9% that Stripe takes.
[1]: https://pixlab.io
[2]: https://paddle.com
[+] [-] wnm|8 years ago|reply
[+] [-] samblr|8 years ago|reply
[+] [-] 256cats|8 years ago|reply
[+] [-] homero|8 years ago|reply
[+] [-] megaman22|8 years ago|reply
I just start checking out when the idea of creating a cloud-hosted, multi-tenant version of our product is raised. Scale, security, liability for data protection, 24/7 operations support, billing, and metrics for billing, all this stuff we don't currently worry much, if at all about, would become first-class concerns. Unfortunately some people seem to think you just wave your cloud wand at things, and poof! everything is magical.
[+] [-] amclennon|8 years ago|reply
I feel like this might become a burden later on when you have to support multiple versions of a codebase in the wild.
[+] [-] brazzledazzle|8 years ago|reply
[+] [-] k__|8 years ago|reply
Especially for Germany/Europe?
If not, why not? Sounds like a good business opportunity.
[+] [-] mtmail|8 years ago|reply
[+] [-] foxylion|8 years ago|reply
[+] [-] marcusbrown|8 years ago|reply
I personally used it for a couple of projects and I'm really happy about it. It probably saved me a few weeks or a couple of months of tedious work!
Workstack https://workstack.io
BrandOn https://brandon.video
[+] [-] mnm1|8 years ago|reply
[+] [-] vxNsr|8 years ago|reply
[+] [-] leblancfg|8 years ago|reply
[0] https://apps.shopify.com/featured/accounting
[+] [-] skittleson|8 years ago|reply
[+] [-] pnathan|8 years ago|reply
I should look into Laravel Spark tho', I hadn't heard of it before and it looks like it might be just what I need.
[+] [-] tnorthcutt|8 years ago|reply
[+] [-] jansho|8 years ago|reply
I want to build a website with a paywall, accessible with annual subscription only. Let’s assume around 5,000 users for the first year. I assume that I can put together a WordPress website with a bunch of payment plugins - sign up, add cart, PayPal, debit card etc - would be enough.
But maybe not? What am I missing here.
[+] [-] Gcam|8 years ago|reply
[+] [-] xstartup|8 years ago|reply
Since all my products are #1 in their niche and I know how dirty businesses especially competitors can play, I do not use any of these bridge services!
There are concerns that these services might sell your customers' data to interested parties or at least roll their own with some insight into your pricing and market dynamics.
We started off using WHMCS. Lots of my friends who rolled their own SaaS got stuck for months changing payment gateways but we just enabled/disabled plugins a few click and kept sailing.
Customers love that we use proven/cheap solution to solve this problem and focus entirely on our app.
[+] [-] unknown|8 years ago|reply
[deleted]