Software Architect / Microsoft MVP (AI) and Technical Author

Business, Developer Life, General Development, MVP, Process Improvement, Productivity, Prototyping, Startups

24 Lessons I Learned Bootstrapping SaaS with Twitter, X, LinkedIn, Facebook, and Instagram for Business API Integrations

This is an expansion of a post on X (Twitter) from a few weeks ago.  For context, here is the original post/tweet:

I hadn't mentioned this as at the time, as there were many layoffs taking place at Twitter (now X).

It didn't seem right to share.

A few months ago, I was on the verge of entering an agreement with an entrepreneur marketplace for my social analytics and content scheduling SaaS.

This would have been a massive boost for user subscriptions.

Then, after Twitter takeover, API and data access was vastly reduced to the platform for 3rd party developers.

(Unless you pay 40k+ USD a month).

This resulted in having to reduce much of the functionality.

With a reduced value prop the agreement being discussed was no longer viable.  I experienced a lot of user churn too.

A double kick in kahoonas.

I thought about shutting the whole thing down and struggled to reconcile opportunity cost v sunk cost for a number of weeks.

I decided to take another swing at it but with a reduced feature set.

I've learned a lot throughout these experiences:

 - build the bare minimum

 - build and ship quickly

 - the less code the better

 - progress is better than perfection

 - gather data and iterate

 - stick with the stack you know

 - outsource as soon as you can

 - leverage old code

 - cloud services accelerate build

 - don't worry about scalability

 - identify metrics you care about asap

 - add logging from day one

 - technology is a small part of the pie

 - do more marketing (text & video)

 - repurpose existing to other forms

 - building in public is effective

 - make deployment processes simple

 - find ways to automate support

 - your idea doesn't have to be unique

 - building on external APIs is high risk

 - prioritise health, fitness, & downtime

 - take advantage of startup programs

 - look out for free cloud credits

 - document key processes



I failed at some of the above.

I may write a blog to expand on this in more detail and how you can avoid some of these mistakes.

Maybe you can relate to some of this.

I learned from @ChanningAllen that @therealjayber experienced something similar.

I have two other SaaS experiments on the go -Audio Notes and Daily Tracker.

We'll see how these perform in the coming weeks and months.

~

I’ve expanded on the bullet points in the original post with further explanations as to why I felt these are important.

I’ve ordered them to make them flow a little differently from the original post.

These might help you.

 

Build the Bare Minimum

If you’re technical or a developer, it can be tempting to add as many cool features as you can think of.

Don’t do this.  Build the bare minimum features.

Implement the features you believe to be most useful.

These will form your MVP or (minimal viable product).

~

Build and Ship Quickly

Building a bare minimum amount features makes it easy and quicker for you to ship version one.

~

The Less Code the Better

Firing up the IDE and building is fun.  It’s rewarding to build and ship product.

More code means more assets to maintain though.

Write as little code as possible. For v1, you may even decide to launch a landing page, pay and run digital ads to gauge demand before opening the IDE.

~

Progress is Better Than Perfection

This speaks for itself.  The UI may not be perfect, the code may need refactored, and your database schema may need tweaked.  If you’re building quickly, you may have cut corners.

Don’t stress about accruing technical debt whilst trying to get v1 out the door.  You can always come back to these things.

Providing your MVP does what the user expects, customers rarely care about the inner workings.

~

Gather Data and Iterate

Your first few customers are effectively your product team.  The next few hundred can become your evangelists.  Gather data as you iterate and fold this into decision making.

~

Stick With the Stack You Know

The technology sector is notorious for jumping on the latest industry trend.  It can be tempting to try the latest technology or framework.

At the end of the day don’t use technology for technology’s sake.  The associated learning curve with a new platform or technology can slow you down.

If speed to market is important to you stick with the stack that you know to help you ship quicker.

~

Outsource as Soon as You Can

When first starting out this can be difficult.  If you are bootstrapping your product, you are likely wearing many hats.

You may be coding, deploying, marketing, and acting as technical support.

This is something I personally grappled with.

If possible, use websites such as freelancer.com or UpWork to find contractors that can support you with activities such as software development or handling technical support.

That’s will give you valuable breathing space to consider more strategic level decisions rather than being stuck in your IDE.

~

Leverage Old Code

You might have an existing solution or code or framework that can be repurposed.  For example, I used an API that I created to perform sentiment analysis online data.  This was repurposed and used in a series of Azure functions that formed part of a SaaS solution.

~

Cloud Services Accelerate Build

When presented with a buy V build decision, I would recommend leveraging cloud services to accelerate any build effort.

For example, there’s no point end generating your own corpus of data to perform opinion mining when APIs are available such as Azure AI Language services can do this straight out-of-the-box.

~

Don’t Worry About Scalability

Don’t worry about scalability when building version one.  Paul Graham of Y combinator has an essay on this very topic.

Worrying about scalability will cause you to write more code than is necessary for version one.  It will also have you wasting time thinking about situations that may never occur.

~

Identify Metrics You Care About ASAP

This might be page impressions, signups, MRR, churn, customer acquisition costs, customer lifetime value, how long people take to sign up, how long pages take to load etc.

Use these to optimize your sales funnel, marketing efforts, identify customer or application pain points and more.

~

Add Logging from Day One

You will experience issues.  Ensuring you have sufficient logging at the application or cloud level and make it quicker for you to identify issues a new product.

For example, I remember a particular issue related to OAuth authentication.  A combination of application insights and web application logging helped me identify the root cause of the issue.

I used the data and insights from both to isolate the code and create a proof-of-concept application to further identify the root cause of the problem.

~

Technology is a Small Part of the Pie

If you’re a developer, it can be tempting to focus solely on the technical aspects of the product.  This is a small part of the puzzle.

 

Some other things to be mindful of are: customer acquisition, how you will handle technical support, handling change requests, keeping the lights on, tax obligations, sales, and marketing.

~

Do More Marketing (text & video)

If you’re technical and most of your time is spent creating and supporting the product, you might want to enlist the help of a freelancer to help you with this.

Another approach is to run alternative weeks with one week for building and one week for marketing what you’ve just created.

This approach can be helpful if you do not have the budget to bring in an external contractor and has also been successful for founders such as Jon Yonfook of Bannerbear.

Do more marketing.

~

Repurpose Existing Content to Other Forms

Repurpose existing marketing content you have created.  For example, a blog can be repurposed into a short video demo, thread for social media on platforms such as X or LinkedIn.

A successful approach is to create open-source projects or free tools under the brand of your main tool that people can use.

For example, I created an open-source SDK that makes it easy for developers in the Microsoft community to consume API endpoints on the X API.

I give away approximately 20% of the internal SaaS API in doing so but it was a good way to raise awareness.  It has been downloaded it over 11,000 times to date.

~

Building in Public is Effective

Another popular marketing approach for solopreneurs and independent developers is building in public.  During product development you can drop updates on social media platforms.

This might be screenshots short clips or simply just sharing updates or your struggles.

A consequence of this approach as you can create a community around your product.  Arvid Kahl has a lot of good content on building in public.

~

Make Deployment Processes Simple and Quickly Repeatable

In the rush to build and ship quickly you may overlook the deployment process.  I made this mistake.

Spending a little time on making your deployment process simple and quickly repeatable will save you time in the long run.

Introduce some basic DevOps practises such as file transformations for configuration files, release management for development, staging, and production environments.

If your product integrates with payment providers such as Stripe, be sure to implement process is that make it easy for you to run transactions from end to end for example creating new and updating new SaaS subscriptions.  I personally found time consuming.

Use schema comparison and database management tools to quickly identify database issues between environments.  Implement version control for your database.

Place new or early release features behind feature flags in your product, gradually exposing them to the wider user base. This will help you perform soft releases and collect valuable feedback without potentially upsetting existing customers.

~

Find Ways to Automate Support

In the early days it can be difficult to manage customer support.

You probably don’t have the budget to pay for a dedicated customer support agent and are likely handling most of the queries yourself.

You can give yourself some breathing space by adding documentation or FAQ guides to your product.

Tools I found useful to handle feature requests and customer support questions were UpVoty and CrispChat.

~

Document Key Processes

Documenting key processes make it simple for you to extract yourself from the day-to-day running of things.

This may include how release processes are implemented or handling customer support.

If it can be documented it can likely be automated, or at the very least, makes it simpler for you to outsource one or many processes.

~

Your Idea Doesn’t Have to be Unique

It’s a myth that your idea must be 100% unique.  You can solve an existing problem in a different way or using different technology.

The chances are if you’re experiencing a particular problem with existing product, someone else probably is too.

Online communities such as Reddit, X, or customer complaint communities are good places to look for ideas.

~

Building Your Value Proposition Solely on External APIs is High Risk

Don’t build your solution around a single API ecosystem.  I’ve lost count of the number of people that I’ve spoken to recently that have either had to shut down or reduce the number of features and their products due to API changes with a third-party provider.

For example, recent changes during the Twitter takeover resulted in many solopreneurs and independent developers closing access to analytics capabilities.

I’ve personally had to disable analytics capabilities in my social media analytics content scheduling and publishing platform.

A single source of anything is a single source of failure.  Diversify.

~

Take Advantage of Start-up Programs

Funds can be tight in the early days.  Take advantage of start-up programmes such as Microsoft for Start-ups and Founders Hub.

Start-up programmes will often provide you with free access to cloud services, networking opportunities and one to one mentorship.

Start-up programmes will help you get to market quicker and can often help give you some additional PR.

~

Prioritise Health, Fitness, & Downtime

Prioritise health, fitness, and downtime. 5 x 5 strong lift three times a week and regular walks in nature help me personally decompress.

It’s often during a long walk my mind will solve a particular problem.  Quite often the best debugging technique doesn’t involve staring at the screen.

In the rush to build and ship product, or handling support and maintenance issues, it’s easy to neglect this.

Prioritise your downtime.

~

Summary

In this post, I’ve listed some of the key lessons I learned with building my own SaaS that integrated with Twitter, X, LinkedIn, Facebook, and Instagram for business.

There were many more but these are some of the key points that stuck in my mind.

What lessons have you learned when building and shipping your own product?

 

JOIN MY EXCLUSIVE EMAIL LIST
Get the latest content and code from the blog posts!
I respect your privacy. No spam. Ever.

Leave a Reply