32 ms·
Hidden work when launching a SaaS
- mijustin 9y agoThis part is so true: "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://spark.laravel.com/ https://bullettrain.co/ https://bullettrain.co/
- wgerard 9y ago> You need to handle payments, and invoices and everything inbetween Isn't this pretty much why companies like Stripe exist?
- mijustin 9y agoStripe just does the processing. But for SaaS, you really need something like https://bullettrain.co/ https://bullettrain.co/. It does pricing pages, subscription and user management (which is what takes most of the time to implement).
- baxtr 9y agoDon’t forget the topic of revenue recognition in SaaS. Basically, you need to allocate your revenues per month if you accept yearly payments. Also, you need to consider up/cross-sells and cancellations, that drive up complexity. I have seen SaaS companies using excel for this...
- konschubert 9y agoThis looks really interesting. Are there alternatives that are built on other frameworks?
- johns 9y agoIt does a lot of the heavy lifting for credit cards, but is nowhere near a full billing system for SaaS. It’s why things like Churnbuster and BareMetrics exist. About 20% of our customers need to pay with something other than a CC, which complicates billing even further.
- unclebucknasty 9y agoYes, but they require integration, which is no small feat. You'll have to wrap their fairly low-level payment processing services into your own business logic. So, it's far from flipping a switch. There is Webhook integration, state management, notifying users, etc.
- mstank 9y agoUnless you have a low cost SaaS product (monthly credit card billing) Stripe is a pain. If you have anything resembling an enterprise sales process juggling dozens of invoices, discounts, payment terms, etc., becomes a hassle. Is there an Enterprise Sales ready billing / invoicing solution? We're using Quickbooks - it leaves much to be desired.
- aidos 9y agoChargebee. It does pretty much everything you can think of and bunch of stuff you can’t ... but will suddenly need one day.
- foxylion 9y agoWe use ChargeBee for our SaaS product. Really great offering! They give you a customer portal where the customer can cancel, update, upgrade, ... his subscription. We have a custom checkout page where all options are listed. Then one API call and the user is forwarded and can fill out billing address, payment information, etc. on a ChargeBee page. They will handle taxes, issue invoice and everything else for you. They have also an extensive API and webhooks.
- homero 9y agoHey same here. The portal feature is incredible
- bacheson1293 9y agosame here....went from rolling our own to Chargebee...so glad we did
- nickjj 9y agoYep but if you want to support other payment types, such as paypal then you need to deal with that too. Suddenly you need to write payment abstractions on your back-end to handle both and most pre-written libraries that try to do this fail because they don't handle cases you may need. That only handles the mechanics of accepting a payment too.
- skrish 9y agoThank you @foxylion and @homero for mentioning Chargebee. Krish, Cofounder of Chargebee here. A lot of our customers use Stripe + Chargebee combination as we complement them by leveraging the best features of Stripe. We like the way Stripe.Js, radar and auto card updater etc is beautifully built. (ex: you can pass Stripe token to create a subscription in Chargebee). We continue to build in a way that we let you use those features while providing a full fledged billing system that integrates all the way from CRM, helpdesk /intercom to accounting. Your finance or sales can collect non card, PayPal payments without any changes to the code. Enabling those business users post implementation with support is our core value prop, so that developers don't have to worry about giving internal solutions afterwards. Give it a spin and for the idea launch stage we have a freemium tier for first $50k usd. If you have any feedback please write to me at Krish at Chargebee.
- aidos 9y agoThank you, Krish! Chargbee has been an awesome experience all round for us and one of my most recommended products. The team have always been ready to jump on a call to deal with the murkier migrations over the years — I'm looking at you, merging our single currency sites into a single multi-currency site... It's nice to see you guys getting a lot of love in all the threads about billing on HN these days. You absolutely deserve it.
- skrish 9y agoThank you, Aiden. I am very happy to see our longtime customers like yourself recommending us in HN. We know there is so much more to do to make things easier and better. I look at Shopify for inspiration to see how long it has taken for them to get their product right by polishing every aspect, feature-by-feature. :) I am sharing this thread with the team. They will be thrilled to read the feedback. Cheers.
- Fredej 9y agoI'm in the process of building a SaaS and looked briefly at Chargebee. Right now I'm trying to stay as lean as possible so I quickly wrote of Chargebee as something that would cost money. The fact that you have a freemium tier completely changes my perspective on that. Guess I didn't spend enough time looking :) I'll check it out!
- trevz 9y agoWe use Stripe, and it's been great. But now we need to start providing invoices and charging different tax rates for different countries ... and suddenly the low-level processing of Stripe just isn't enough.
- tarstarr 9y ago(I work at Stripe) We're actually beta testing a new product for invoicing. Shoot me a note (tara@stripe.com) if you're interested and I can get you into the beta.
- paulie_a 9y agoThat is not Enterprise saas in my experience. That is someone signing up for a 20-100 dollar a month service. A 40k a year contract is a bit different
- PeterisP 9y agoIf you sell 40k a year contracts, can't you just have a sales assistant maintain the custom terms&conditions&discounts and draft personalized invoices manually until you have many such contracts and automation starts to make sense?
- hbcondo714 9y agoThanks 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. [1] https://aspnetzero.com/ https://aspnetzero.com/
- yread 9y agoLooks really interesting! Will definitely keep it in my mind for the next app... It seems it's a bit more expensive (and does more) than Laravel. Can you talk about your experience with it?
- hbcondo714 9y agoThey recently hiked up their prices b/c now it includes a Xamarin mobile app but their back-end and middle-tier is free & open source[1]. We opted for the paid version because our team is small and we are building a new multi-tenant SaaS. It's going well but the primary challenges we have are porting our existing data into their data model which right now uses SQL Server and some Redis. The paid version comes with descent support via their premium forum[2] but they have their own tag on StackOverflow[3] [1] https://github.com/aspnetboilerplate/aspnetboilerplate https://github.com/aspnetboilerplate/aspnetboilerplate [2] https://forum.aspnetboilerplate.com/viewforum.php?f=5 https://forum.aspnetboilerplate.com/viewforum.php?f=5 [3] https://stackoverflow.com/questions/tagged/aspnetboilerplate?sort=newest https://stackoverflow.com/questions/tagged/aspnetboilerplate...
- yread 9y agothanks!
- rkuykendall-com 9y agoThis is really cool. Do you know if there's something similar for Python/Django?
- slig 9y agoAny recommendations for a Django alternative to Spark?
- robgurley 9y agoAnd 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.
- forgotmysn 9y agoGood. It's about time start-ups started taking that responsibility seriously.
- robgurley 9y agoI sort of agree? I think it's important that people take data privacy and security seriously. I don't think someone, however, needs a nuanced understanding of what constitutes legitimate interest for data processing, or needs to have an attorney from every country or region they do business in on standby. The issue is that vendors (CRM, marketing automation, etc.) are trying to offload too much of the risk and accountability to their own end users, which leaves startups piecing together tech stacks that are sometimes not even legally compliant in their default settings. Not OK.
- forgotmysn 9y agoThat's definitely true, but I'm not too worried about it. It will be a short-term headache, but I think eventually processes will be refined and new models of responsibility will evolve.
- kolinko 9y agoIt's not about responsibility, it's about the unnecessary red-tape.
- jotm 9y agoI'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.
- k__ 9y agoAre there any SaaS that do all these things for SaaS? Especially for Germany/Europe? If not, why not? Sounds like a good business opportunity.
- foxylion 9y agoYes, as mentioned in my other post, ChargeBee does this really well. We, as a German company, use it for our SaaS offering.
- baxtr 9y agoDo they also do revenue recognition for you?
- aidos 9y agoRevenue recognition isn’t something I know anything about (see my comment above about chargebee doing a bunch of stuff I don’t even know I need) but here’s their page on it https://www.chargebee.com/docs/revenue-recognition.html https://www.chargebee.com/docs/revenue-recognition.html
- baxtr 9y agoAwesome! Thx
- mtmail 9y agoWe (SaaS, https://geocoder.opencagedata.com/ https://geocoder.opencagedata.com/) use https://quaderno.io/ 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.
- homero 9y agoI use https://www.chargebee.com https://www.chargebee.com, they've been incredible
- deleted 9y ago[deleted]
- dalfonso 9y agoYes, 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.
- btown 9y agoSoft-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.
- saurik 9y agoCreate a view and have everyone use the view. Name the original table something like "table_with_deleted_records" to make it stupidly clear what is going on.
- sbov 9y ago+1 on the soft deletes. It potentially adds a corner case to everything you do with that record. It's a permanent tax on your productivity. 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.
- jamesvandyne 9y agoauthor here. You’ve hit the nail on the head. 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.
- jimjimjim 9y ago"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.
- pnathan 9y agoThis 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.
- tnorthcutt 9y agoI'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.
- symisc_devel 9y ago> 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. [1]: https://pixlab.io https://pixlab.io [2]: https://paddle.com https://paddle.com
- wnm 9y agoI can second the recommendation for paddle. I use it for https://presskithero.com 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!!
- samblr 9y agoAlso, Paddle costs more per transaction. Stripe charges fixed 20 cents / transaction and Paddle 50 cents.
- 256cats 9y agoI second this, we use Paddle on https://gimmeproxy.com 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.
- megaman22 9y agoThis 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.
- amclennon 9y ago> 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 feel like this might become a burden later on when you have to support multiple versions of a codebase in the wild.
- brazzledazzle 9y agoYou 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).
- cyberferret 9y agoThis 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').
- aidos 9y agoTo 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.
- cyberferret 9y agoI applaud what you did, because you are essentially being honest here with how you went about it. The only way to accommodate shoe horning in a billing system in that amount of time is, as you said, to 'hack' a rudimentary system together, and to do some of it manually. That is perfectly understandable. You would also be aware of the technical debt that you built up by doing it this way - debt that will have to be paid off later with either a complete redesign, or else major functionality addition to keep pace with all your customer requirements. My issue was with those who intimate that they deliberately left off any form of payment functionality, then managed to get a fully working engine up and running perfectly in a couple of weeks.
- mrkurt 9y agoThis 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 agoYou 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 agoNice blog post, but just as a heads-up, he never actually defined what "JIT" stands for in the post...
- mooreds 9y agoI 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.
- LeonM 9y agoIn 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.
- jansho 9y agoThese 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. But maybe not? What am I missing here.
- aidos 9y agoYou need to think about the tax implications which depends on whether you're selling to businesses or individuals and which countries you and they are in, amongst other things. I'm basically banging the Chargebee drum on here because they'll take care of all that for you.
- Silhouette 9y agoTaking the money is (relatively) easy. Plenty of payment processing services will help you with the mechanics of that these days. As many of them enthusiastically demonstrate, the basic charging mechanism often requires just a bit of information to sign up and then a few lines of code (or a simple plugin for WP) to implement. You're probably right about putting that together without too much trouble. Unfortunately, then you get the other 90% of the job, because you're a business and charging money, and that comes with all sorts of legal, accounting, tax and regulatory obligations that will vary depending on the place(s) you do business and the place(s) you find your customers. This is the stuff the flashy "Take your first payment in five minutes" demos on the homepages of all the payment services don't tell you about, but if you're lucky your accountant might. (If you're less lucky, you might need a more experienced accountant but won't know it, and you might wind up making expensive mistakes. Doing a lot of reading online about the rules that apply in your specific location, for example if your government's tax department offers any guides for new businesses about what they generally need to do, is the only reasonably effective solution I know to this problem.) In practice, these things almost always come down to (a) identifying the relevant tax rules based on your location and your customer's (b) calculating the correct tax on sales, as well as on any payment processing fees, etc. (c) keeping complete, accurate, systematic records of all transactions (d) filing the necessary tax returns and/or providing the records to your accountant so they can do the serious business financial paperwork (e) paying your taxes properly. None of it is rocket science, it's just that it's often a big, complicated system that you have to work within, and it's full of little details like generating sequential numbering for invoices, or knowing how to handle the tax if you've issued a refund before/after the end of the tax reporting period containing the original sale, or being able to record two non-conflicting pieces of evidence to confirm which country your customer is in. It can be time-consuming and error-prone, and taking enough professional advice to understand your obligations and how to do everything correctly can be a significant expense by start-up standards. Finally, depending on your market, you may at some (possibly quite early) point want to accept payments through more than one channel: purchase orders and payments to bank accounts, online credit cards, the various direct debit schemes or national card schemes, PayPal, and so on. If you're in that position, the "front line" payment processing services like Stripe or PayPal are unlikely to be sufficient, because it's a level above what they're designed to do. So probably you will either need to use one of the next-layer-up services such as those mentioned elsewhere in today's discussion to co-ordinate things, or you will need to do some substantial programming and database work of your own to do something intelligent about combining the functionality and record-keeping for each service.
- vxNsr 9y agoSeems 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.
- leblancfg 9y agoShoehorning Shopify to your SaaS is probably quite straightforward. There are plugins for accounting stuff, too. [0] [0] https://apps.shopify.com/featured/accounting https://apps.shopify.com/featured/accounting
- vxNsr 9y agoExcel can be your tax template, but people would still rather use dedicated software.
- ttoinou 9y agoIsn't there a front and back end software to deal with this kind of stuff easily ? Like magento https://magento.com/ https://magento.com/
- warent 9y agoGood point but have you tried using Magento? It's a beast into itself and typically requires an expert that knows how to configure and use it
- ttoinou 9y agoThen what is the competition for Magento ? I would like to launch a SaaS in the future and I really don't want to spend my life building a client database, stripe stuff and support platform...
- TomGullen 9y agoDid this for our new product Construct 3: https://www.construct.net https://www.construct.net It was difficult, but built some good features that do give us a lot of flexibility: * region based pricing * region based billing cycles * multiple plan options per region * auto generated pricing based on live fx rates which ar rounded “nicely” which is harder than it sounds *% based discounts and account credit * ability to modify seat counts Difficulties amongst many many others are: * VAT handling (it’s different per customer type and country!) and generally having a solid grip on business finance * abstracting it to allow multiple payment methods (stripe and PayPal) * generalising it enough to support multiple products * dealing with fx changes during checkout * handling disputes, refunds, etc and their affect on product access * just PayPal in general god damn! When dealing with b2c not including it is tempting but not really and option. PayPal and stripe in my experience give 99%+ coverage Easy bits are the generating of invoices (prefer to do this in house) and all the other trim like emails etc. That’s just grind work. I’m proud of it though and so far we’ve done 6 figures through it and is holding up well (tens of thousands of LOC and probably around 6 months dev time). We wanted it to do a lot and the design is quite sophisticated I think. Second payment system with meat on it I’ve written (first cleared 7 figures but is no where nearly as well designed and mainly deals with one off payments). I enjoy making them! Would definitely of bitten off more than I could chew if I was less experienced. Making it all scalable and reliable is another layer of complexity. One gotcha which is hard to manage on a business level when dealing with sass accepting multiple currencies is forex rates that become very out of sync with your orginal price points. Can explain more but on phone! Still to do is adding a system for accepting POS, a lot of the difficulties we face is we sell to the whole market, consumers, businesses of sizes and education. When selling to education specifically offering native currencies is a huge competitive edge especially for sass. Also still to do in a more elegant way is b2b enterprise customers sometimes like paying for multiple years in advance - high value orders so another important case to cater for! ALSO still to do is create accounts for resellers to buy at discounted rates. You can see how much work is involved on this sort of thing! Winging it with “it works” won’t cut it imo (9/10 I’m all for it!) - that is the gooiest technical debt you can take on. Imo you need to seriously invest time into a good design from day zero.
- yathern 9y ago
- protomikron 9y agoWhat about the unhidden work, like "Describe your SaaS, i.e. what is kwoosh?". Sry, that was snarky, but you really should describe your service, as I could not find out what it does.
- jamesvandyne 9y agoDid you view our marketing site at https://kwoosh.com/ https://kwoosh.com/ ? Good point though, we could update the footer on workshop to be a bit more specific.
- protomikron 9y ago> Did you view our marketing site at https://kwoosh.com/ https://kwoosh.com/ ? Yes, that's what I am referring to, the workshop-link goes to some kind of blog, but it seems to be more about tech and entrepreneurship in general. Some kind of "About" section with screenshots would be nice.
- jamesvandyne 9y agoThank you for the feedback. Yes - more screenshots / a properly filled out marketing site are on the list of things to do. Good idea about an "About" section. Workshop is the name of our blog where we show / discuss Kwoosh as we build it.
- mnm1 9y agoThese "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.
- skittleson 9y agoThe 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 http://amzn.to/2H8isRI).
- xstartup 9y agoThere 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.
- Gcam 9y agoI 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.
- marcusbrown 9y agoThese are exactly the pain points that Taylor Otwell (creator of Laravel, a PHP framework) tried to solve with Spark (https://spark.laravel.com/ 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! Workstack https://workstack.io https://workstack.io BrandOn https://brandon.video https://brandon.video