Recently, I was talking to a friend who likes Croissant and wants to take it to a new industry: recording studios. Instead of bouncing around between coworking spaces, music artists would be able to bounce around between different recording studios in NYC with one monthly membership. The friend — I’ll call him Bob — likes the platform as it is, with its current feature set, and hopes that we will let them “white label” it for use with this new purpose.
This got me thinking. I wondered how we could pull this off. My initial reaction was (assuming we worked out a licensing deal), even if we changed the branding and sent over all the code, someone still needs to maintain the servers and the database. Bob is not technically savvy enough to do this, so he would either have to partner with a technical co-founder, teach himself how to manage it, or have us manage it. I, of course, always recommend teaching yourself how to code because it’s a lifelong skill for any profession.
Any which way, the deliverables would likely be one of two things: (1) The complete code base, allowing Bob to change things on the fly, or (2) only admin access to a back end tailored for his business, where we take on the responsibility of changing the site as needed. To achieve either one, here’s what needs to get done:
Form an entity
Keep things simple and correct. Back in the day, we used Clerky to form our Delaware C Corp with the assistance of a lawyer friend. I’d still recommend using their service, or something similar. It’s fast, it’s easy, and it’s cheap.
Get a DUNS number
Bob needs this for the Apple App Store. It’s a painfully old government website, but there’s no way around it, unless you submit your app to the App Store as an individual. But no, he should do it as an entity for consistent branding.
Get a bank account
Just get a simple business checking and/or savings account. Bob will need this to collect payments from customers via payment processors (see below), paying out partners, and business expenses.
Get a domain & social media accounts, and start socializing
This is an ongoing process from day 1. Try to get the company name on Twitter, Facebook, Instagram, Medium, Reddit, and others. If it’s taken, try prefixing it with “use”, “get”, or “app”. This ties into our white labeling process because some of the code on the website and app redirects to these accounts, such as the option to tweet a workspace check in, or just link to our social media from the website footer. As per the website domain, we recommend namecheap. Their live support team is phenomenal.
Get a Stripe and Braintree account
This is what our codebase uses to collect payments for credit cards and PayPal. You probably only need Braintree for both, but we started with Stripe for credit cards, and haven’t yet completely migrated over to only using Braintree, but it should be possible in theory. However, if Bob is using our code, he still needs Stripe. Also, with Braintree, it can take a few days to get approved for production capabilities, so don’t save it till the last minute.
Provision Amazon S3 buckets
We use these to store pictures of the workspaces as well as profile pictures uploaded by our users. Bob can skip the painful job of figuring out how to do bucket permissions on AWS because we already figured it out for our purposes :)
Get a Sendgrid account & add host records
This is just for outbound emails. Also, branding is key. Bob needs to make sure he adds the necessary host records to his domain so that the emails look like they’re coming from his domain. We also use their templating system so every email we send is branded. This will have to be updated with the new company’s logo, wording, and social & website links.
Make a new API server code repository
Bob should make his own GitHub account and then take the code we send him and push it into a new private repository. We follow industry standards so none of our passwords are in our codebase. They are all set using environment variables wherever they are deployed, such as Heroku.
He can then use that repository for managing the project, and use similar git commands when it comes time to push to Heroku. Branding doesn’t matter that much for the API, except the wording of some server responses.
Make a new web app repo and replace names and images
Right now we have this as part of the same repo as our API server, but we really should be good samaritans and put it in a separate repo. Anyway, using Cmd+Shift+F in Sublime and searching for “Croissant” will help us get a sense of the breadth and depth of the changes in question. After all the keywords are replaced, together we would go down a checklist of features and make sure everything is working and branded correctly. This includes making sure unit tests, integration tests, and end-to-end tests all pass successfully.
As per branding, all of the copy and images on the website will have to be replaced. There’s over 100 images that need to be re-created and thousands of words of text that will have to be rewritten. And it’s not as simple as only replacing those things. The overall site layout is greatly affected by the content, so there will also likely be a prolonged period of experimentation with the layout.
Make a new mobile repo and replace names and images
This is another place where “find all” will be useful in identifying the places where the word “Croissant” is. Luckily, we use Ionic Framework, which is built on Cordova, so the changes will affect both iOS and Android apps, making this considerably less painful. Don’t forget to make new app icons too!
Get a Heroku account and addons
Bob should get two apps running on Heroku: a test server and a production server. For the test server, he just needs MongoLab, deploy hooks, and some sort of logger, such as PaperTrail. For production: it would be those three, as well as Newrelic for app monitoring and SSL + Expedited SSL for quickly provisioning security. SSL is required for accepting payments with Stripe and Braintree. Why deploy hooks? That’s for Slack integration purposes, so the whole team sees when there is a new deployment.
Deploy the server & web app
Once the website is ready, all Bob has to do is push the code repo to Heroku. He’s not done yet though, as he will need to populate the database with the products he is selling. We have some proprietary back end interfaces for doing that.
Submit the mobile app for approval
This part takes a while so he should try to submit the app about a week before launching the website. Then, when it is approved, he should submit the Android app for approval from Google Play, which should only take a few hours. When both apps are approved, he can manually release them at the same time. Don’t forget you need a DUNS number before making the Apple Developer account for your business, so do that as soon as possible.
Go forth and sell
The whole time all of this is going on, Bob needs to be constantly putting out content and networking with potential buyers of the product, both online and offline. Don’t fall into the “Build it and they will come” mentality, and figure out your distribution channels before launch. When he launches the product, he needs to be in a position where he can quickly measure how people react to the offering, and adjust as necessary.
It should take a few months to get all the legal stuff sorted out. During that time, all of the technical aspects of the migration can be completed. Once that is in place, he can start selling memberships as soon as the live website is deployed. Before the website is live, Bob might also want to consider using LaunchRock to capture email addresses and engage potential users.
I figure that’s pretty much it. I feel like I’m forgetting something important, so please, if you have any experience with all this, let me know. I’d love to hear about it!
Dave
Co-Founder & CEO, Croissant
p.s. This is just a thought experiment. This white labeled venture is unlikely to happen anytime soon.
