How We Launched Our SaaS in 1 Week

The Challenge

Last week we took on an ambitious challenge — build a complete SaaS product in a week. While we didn’t quite hit our 1 week deadline, we were able to launch a complete product to the public 2 weeks later, and by the time we had launched we had already verified our core ideas and UI with our target audience.

We learned a lot through the process, and by leveraging a number of existing services we were able to quickly build a completely new product called SegMetrics — which provides powerful analytics for Infusionsoft users — and begin marketing it almost immediately.

I consider this project to be a great success for us — and for our way of developing products — so I thought I would share how we did it. I’ll go through what worked, what didn’t, as well as list the tools and strategies that we used to build our new product.

Table of Contents

• Why We Did It
• The Idea
• Validate Quickly, Validate Often
• The Tenets
• Staying Out Of The Weeds
• The Non-Tech Part Takes the Lion’s Share of the Time
• Your Tech Stack Should Work for You
• Marketing Process
• Our Complete Timeline
• Conclusion

Why we did it

Last December Nathan Barry posed his 24-Hour Product Challenge where he built, and challenged others to build, an information product in 24 hours. He built and launched 10 Days to Better Design and Amy Hoy launched JFS (Beware: expletives abound at that link).

Amy and Alex’s JFS is a no-holds-barred look at how to go from an idea to a product to actually SHIPPING it in a short timeframe. It talks about many of the same principals that I help my clients with — working on shipping small products first and quickly creating products that people actually want to buy.

There are a lot of people out there with ideas that they want to make a reality but for some reason or another are not able to develop them into full products. I know that because at DelfiNet we work with people, startups and companies to help build out ideas into fully realized products.

But there are also a lot of people out there who don’t know where to start, or don’t have the funds to start, or think that the first launch of a product has to be a fully-realized 100% system with all the bells & whistles, an attached email client and worldwide distribution network.

What I’m going to show you is that to launch a successful product, you don’t NEED all that. What you need is a problem, a solution and a well defined project scope. With that, some elbow grease, and an overbearing sense of pragmatism, you can launch your own product in a week.

Scope Creep Kills All Projects

For the last 4 years, DelfiNet has been working with companies who want to launch new products, or build internal tools to accomplish their business goals. For over 6 years before that, I had been doing that as part of my day job as a Japanese salaryman — working with companies like Toyota, Sharp and NTT to build what we call “Beautiful Technology.” Over the last decade, we’ve worked on $10k projects, $100k projects and $1mm projects for both startups and enterprise companies.

Why do I mention that? (Besides the fact that building a consumer-facing product for Toyota is really cool?)

Because there is one critical factor that I have seen that separates successful products from failed products.

Scope Creep.

For those that aren’t familiar with the term scope creep — it refers to uncontrolled changes or continued growth in a product’s feature set. Essentially adding more and more to what a project is supposed to accomplish until success becomes impossible. But what many fail to realize is that scope creep can start even before a project gets started.

As a product creator, you have a ton of ideas, and want to create the best solution you can possibly think of. And one of the great things about working on an idea is that the more you think about it, and the more you build, the more new ideas you have. It’s a great problem to have, but if you don’t exercise some pragmatism scope creep becomes a project killer.

I have seen more than my fair share of projects never materialize because there was “just one more feature” that was needed before launch. Or seen a project that could have been launched as a lean MVP balloon out of control, both in time and cost, because of scope creep. And this isn’t an issue just with clients. I’ve fallen into the same trap. It’s hard to stay focused on a single feature set or goal when you have so many great ideas running around your head.

But lack of focus is what causes you to lose control of a project — and it’s what turns a 1-week MVP into a 4-month monolith that has all the features you THINK you need but may not be what your customers want.

The Idea

Getting back to the 1-Week Launch. The idea for the product came from consulting work that my co-founder and I do. He’s an incredibly talented data analyst and we have worked together on a number of client projects in the past. We were bemoaning the fact that Infusionsoft, the new hotness of the online marketing scene, has amazing data capabilities but doesn’t present the data in a way that is meaningful to online marketers.

Why wasn’t there already a SaaS product that gave Infusionsoft user clear and powerful analytics? Converting PPC leads and webinar traffic is so critical for many Infusionsoft users, but how are they measuring the value of these leads? Do they all export a million spreadsheets a week from Infusionsoft and pull out their hair in Excel? Because that how 90% of our clients do it.

Lifetime Value of a Segment Lead over 14 / 30 / 60 / 90 days

There had to be a way to make this simple and give people data they can actually use. And if we had these frustrations with Infusionsoft, certainly there was a sizeable market of people who shared our frustration. Thus, our idea was born.

Reflecting on our idea, I was instantly reminded of Baremetrics, which provides a similar service for Stripe — making powerful data and metrics more accessible to the people who need it. It sounded like a good fit and an interesting project to try out. Worst case scenario, we had a new tool that we could use for our consultancy.

Now that we had an idea, we needed to validate.

Validate Quickly, Validate Often

One of the key tenets of the Lean Startup mentality is to continually validate your ideas with your customers and the marketplace. Companies generally accomplish this through idea sheets, tech demo, designs and interactive mockups, all of which they show to potential customers.

We already had an idea, so our first step was seeing if people would be interested in the data. We asked to borrow access to some of our clients’ Infusionsoft accounts and quickly put together a report of the data we would be providing them.

This is, I feel, a key point that many product creators miss. People who are not you have an imperfect understanding of your idea, and it’s often difficult to describe in words or gestures exactly what your product will do. Sometimes just explaining is enough, but showing a potential customer what THEY would be getting from the product in your tech demo, with their live data, can be a great way to judge actual desire for the product.

We sent our initial report (just 8 lines of key metrics) to our clients and asked how valuable those numbers would be to their business. The results were universally positive, so we went to the next stage: the MVP.

Skype chat where we sent out those key metrics to our potential beta users

During the MVP process (which I’ll talk about below), we focused on pragmatic programming. We developed features in order of what could be used to quickly build a version to show our beta-testers and to get feedback on how we were analyzing the data. That means that things like “billing” and “editing accounts” came later, and the key metrics dashboard came first.

And it’s a good thing we did too, because our initial assumptions about what data people wanted were off. (Specifically how we tally things like value over time for a segment, who is included in a segment and what purchases are included in a segment when you’re limiting by a timeframe.)

Graphing Revenue based on lead segment

All clients are different and want different metrics, but we needed to find the core metrics that were universal to our target market and leverage them in a way that both was actionable for their business and could be easily understood.

This led us to our 2 core metrics. When we added them to the interface, all of our beta testers’ faces lit up.

1. Lifetime Value of a Lead over 30 / 60 / 90 days
2. Lead Value of a segment for a given time frame

These are two numbers that are INCREDIBLY important for an online business and very difficult to get from standard reporting. Those became our two “sexy” numbers, and everything else serves to provide users with a deeper analysis.

The 3 Tenets for SegMetrics

This is our second SaaS product that we’ve developed internally, our previous being Summit Evergreen, a full-stack courseware solution for people wanting to develop informational courses online. Whlie Summit Evergreen is a very sticky product, it has a high-touch on-boarding process — people need to have a course in mind, or course content that they can then import into the system — before they can sign up. People don’t switch their courseware platform on a whim, so our customers generally research Summit Evergreen for a while before they sign up.

For SegMetrics, we wanted the core tenet of the software to be “5 minutes to awesome.” That means someone who has never heard of us before can sign up, and as long as they’re using Infusionsoft, will have actionable metrics in less than 5 minutes.

So tenet #1 for the software was “5 Minutes to Awesome”

Awesome!

Our #2 tenet was “Actionable Data.” Many metric systems are built for data analysts — they provide lots of number-crunchable data, but very little actionable data, because that’s the role that analysts usually perform. We wanted to make this a tool that everyone can understand, and analysts can use as a quick overview of all their metrics.

Our #3 tenet was for the development team — and that was “pragmatism.” It’s one of my strongest beliefs that developing applications is best done from the bottom up — you build the foundation (scaffolding) before you build the core features; and you build the core features before you work on the UX improvements and “cool to have” features.

This was especially important as we were working to get the project done in one week — we just didn’t have the time to play around with things that are a nice-to-have, but didn’t drive the launch forward. I set a time limit of 50 hours in Harvest for us to get the first version out the door. Since we were starting with a new framework, we had a lot of “boilerplate” work that we had to get done in that 50 hours.

Our loose roadmap was:

1. Have an “Integration” that connects to a single Infusionsoft instance
2. Import and parse all the necessary metrics into a usable format
3. Have a “Segment” that represents a tag in InfusionSoft, and allows us to find users who have that tag
4. Calculate our core metrics for users in a Segment, based on a timeframe
5. Graph that sucker

Once those 5 points were accomplished, we could show it off to our beta users with THEIR live data.

Staying Out of the Weeds

This is one of the hardest parts when working on a project — you want to do everything “right” the first time. The problem is that “right” is often a mutable factor, especially when you’re still in the MVP phase. It is often better to get things to a working state than getting it to work 100% “right.”

Two big parts of SegMetrics that got us into the weeds were our graphing functions and our data queues.

Our graphing functions can require joining over 300,000 pieces of data and our initial run of it took around 10 seconds to run. This was “unacceptable” and we spent a day optimizing MySQL queries.

While it’s important to optimize our data visualizations, it was not our number one concern and it should have been pushed to later. Our beta customers don’t care that they have to wait 10 seconds for the graph to display, and we want their feedback on our graphed data more than we want to waste a day optimizing queries. In this case it was doubly hurtful, because the data that we were originally getting was not what the users wanted and we had to rewrite the queries anyway. If we had forgone optimization to later we would have realized the issues with our queries sooner and been able to save time.

Our second part of weeding was with the Queue. We grab and process a LOT of data (around 1 to 2 million entries for a “Professional” level customer) and of course need a queue process to get that working. But, as we are engineers and like working on hard problems, we started on the queuing process even before we had a user interface.

As with the queries, our beta users don’t care that they have to click a button to gather their data instead of it happening automatically in the background. And our server didn’t care that, because we had only a few beta users at the time, we use a single cron job instead of a real queue for data-getting.

We now have highly-performant queues and queries (more on that below), but we were able to accomplish those while we worked on the marketing and non-technical aspects of SegMetrics. This allowed us to focus more on immediately responding to user feedback — at one point we updated our data-analytics rules 10 times in a single day based on user feeback — rather than spending that time building backend systems that didn’t help our beta users engage with our product.

Overall, though, we were very diligent about staying out of the weeds and on track with our development plan. We were pragmatic about what we decided to leave in for launch and what got pushed to after launch.

One of the main things that people starting their first product fail to realize that there is MUCH more time after launch then there is before launch. You can launch with the bare minimum, and before you have 50 customers you will have had more than enough time to add in 90% of the features you wanted.

And if you get 50 customers in a week of launching? Congratulations! This is what is known as a “good problem to have.”

The Non-Tech Part Takes the Lion’s Share of the Time

This is one thing that most people who are thinking about building a product don’t realize — development is really only a small sliver of the overall time-cost of launching a product. Things like logos, setting up email, getting your social media account, writing copy for the front page, writing an FAQ, deciding on pricing, privacy policies and setting up Google Analytics and your marketing emails all take as much time — if not more — than the actual development.

And after finishing all that, you’ve only SET UP your marketing. You haven’t actually started marketing yet.

Our marketing efforts started very simple. After installing all the required tracking we started with some low-budget Facebook ads to test the waters with our messaging. We also did the obligatory posts on news networks that our target audience follows, as well as sent out notifications to our email lists and social media followers.

One of our first ad variations. 7.5% CTR. Outperforms our worst version by 124%

(I’ll go into the full details of how we started our marketing process below.)

Maybe we should have done a “proper launch” where we built up expectations to pre-launch events, etc. But at this stage in the game I felt it was more pragmatic to just launch and pivot our strategy from user feedback rather than building up a “launch event” model.

We were determined to stay focus on what was essential — and keep to the challenge, which was to build a fully functional product within the timeline. A pre-launch may have made more sense from a traditional sales perspective, but did not fit with the spirit of the challenge: “Launch now, and Launch hard.”

Also, I’m generally so busy with client launch events that I didn’t want to spend the 2–3 weeks working on a launch for SegMetrics.

Your Tech Stack Should Work for You

There are a number of factors that go into deciding on your tech stack. Familiarity, speed of development and future maintainability are probably the largest. We do most of our work in PHP and have been working with the Laravel framework over the last couple of months. Laravel is one of the more flexible and modern PHP frameworks out there and it has all the right balances between configuration, convention and customization.

We used Laravel with Vagrant (Homestead) for our local development which gave us a quick startup in a VM with everyone using the same virtual hardware and configurations that would be on our live server.

We used Bootstrap for our frontend and customized it with our own stylesheets, using Less.

One thing that we spent a little extra time on is getting our frontend and compiling frameworks working. If this was a true “quick and dirty” launch I would have gone with a less robust compiling and deployment strategy, but I plan to use this workflow in the future, especially when we start building our “SaaS Starter Pack,” so I felt that the extra time was well-warranted.

Deployment

One thing I am a big proponent of is ease of deployment. I have worked on a number of projects that as they grew took longer and longer to deploy, at which point the site went down while the code was switching over. It made deployments a thing you had to plan carefully, and I have noticed that long deployment jobs make people put off feature improvements because of the perceived cost of deploying. When your deployments are easy to do and happen instantaneously, developers are much happier to jump in and fix an issue right away because there is a lower perceived time cost to the fix.

To put this in more generic terms, if you think it will take you 15 minutes to answer an email, you are more likely to delay answering that email than an email you know you can answer in 5 seconds. Things with a high perceived time cost get deferred while things that are perceived as quick wins get pushed to the front of the line.

Our Tech Stack

Here is a quick rundown of our tech stack — this is not the end-all-be-all of what you should use, but gives a good introduction to exactly how many technologies go into building an MVP.

Framework & Language

We used Laravel, which is a MVC PHP framework. We thought about using something like Angular for our frontend, but with the low amount of frontend dynamic content it made more sense to go with a standard PHP page and use Ajax to load graph data.

Frontend & Visuals

I’m a huge fan of Bootstrap. It provides not only a great grid system with useful components, but also sets a great naming convention for developers to extend on and build a logical structure between the components and their visual aspects. I pulled in the Bootstrap files locally and compiled them with Gulp, as that gives me more flexibility than just overriding the styles from the compiled CSS.

For icons we used FontAwesome. Supplemental icons and iconic images are from the Noun Project. If you want to make your own font sets for icons, I recommend Icomoon. You can import Font Awesome and your own SVG icons to create a single font package that has all the fonts for your app. (We use Icomoon to compile the custom icons for Summit Evergreen.)

Charting is done by Chart.js. We’ve used NVD3 and Rickshaw in the past, but Chart.js has really matured in the last 6 months. It loads quickly, uses a very sane data format and is greatly customizable. I used to use Google Charts long, long ago, but the data format they use is so different from anything else on the market, and so complicated, that it makes little sense to use them when better solutions exist.

For cool animations we use animate.css, for drop-downs and tagging we use Select2, and for our date range chooser we use Improvely’s bootstrap-daterangepicker. For pretty checkboxes and radios we use iCheck.

Our signup form has some nice auto-formatting for credit cards. We use Stripe’s jQuery.payment for that — it gives a lot of extra hints and polish to the credit card form and works right away with the standard Stripe checkout.js.

(If you can’t tell, I’m a HUGE frontend library collector. One of my guilty pleasures is looking at places like unheap to see the latest cool things we can do with frontend UIs.)

Frontend Compiling

As much as I love frontend frameworks, this is the first time I’ve ever used a frontend asset management system like Bower or Gulp. I had stayed away from Bower because they don’t support locking deployed versions to a certain hash-sum, which means that if a library updates an existing version of its code, there may be breaking changes when you deploy because you’re not guaranteed to have the same checksum as your local version.

It also means that if you don’t set the EXACT version of the library then you may have some nasty surprises when the production version of your code has a different version than your dev version does. This actually happened to us with Gulp.less, where the 2.0.3 version had a major bug that broke all path syntax.

People say you should commit your Bower-managed packages into your git repo, but that just makes no sense to me. If I wanted to commit libraries into my repo, I wouldn’t be using a package manager.

Anyhow, I definitely recommend Bower for package management — it just makes things so easy. Gulp I use for concatenation and parsing all my less files. It has some great features that allow you to customize it specifically for your workflow, and I found it actually easier to use than Laravel’s Elixir (which is a wrapper around Gulp).

As a point of note, I was always against using Bower and Gulp because I didn’t want to have to deal with multiple language runtimes just to deploy my software. I wanted all my solutions to be PHP-based. After fighting with that for months, though, I have to say it just makes life much easier to go ahead and install Ruby and Node on your machine so you can use these tools. They’re the best for the job and it makes your life so much easier than having to fight through semi-supported compilers and workarounds when you could be providing value to your customers.

3rd Party Tech Services

Our servers are on Digital Ocean, and we use IronMQ for our queues. Using IronMQ instead of something like Beanstalk and Supervisor gives me peace of mind that something hasn’t fallen down without me knowing and lets me monitor my queues easily without having to take up resources on our servers. I’ve had enough horror stories of queues failing and generating infinite jobs and just all the badness that can occur to want to deal with any process that can fall over. I’m also looking at IronWorker for our queue workers, so we can get some better burst performance for initial customers.

We use Papertrail for logging. This is the first time I’ve used Papertrail and I am kicking myself for never having used it earlier. As I mentioned earlier, tasks with high perceived costs get delayed, and the idea of crawling through logs was never high on my list of things to do during a day. Papertrail makes it so easy, and I can monitor it from anywhere at any time. (And dear lord the number of people trying to log into SSH. I need to change that port to a non-standard one ASAP.)

We use Deadman’s Snitch for monitoring our Cron jobs. This is one of those things that is so simple that I’m surprised no one thought of it sooner. It has already saved us twice when an update caused the data queue functionality to die under certain circumstances. I knew there was something wrong within 30 minutes of the bad deploy.

For sending emails from SegMetrics, we use Mailgun. We also use it for our standard segmetrics.io email addresses, which we then attached as an extra account to GoogleApps. It took a little bit to set up the first time, because we had never done it before, but gives us a TON of flexibility with setting up email routing and support tickets. Also, all our emails are routed through MailGun now, so we can track views and clicks even on our standard correspondences.

For our system emails (forgotten password, etc.) we hook in through MailGun’s API and use a custom Laravel mail class with CssToInlineStyles to inline all the CSS into our mails (because 90% of clients don’t support styles in the header).

Deployment Process

One of the features I wanted to have for this project was a smooth deployment process. Working with a number of clients, we’ve run the gamut of deploy strategies, from FTP to Jenkins-deployed ANT builds. Our most recent solutions are Puppet-backed and are deployed through Jenkins, but the way the systems are set up it can sometimes make it a hassle to deploy.

For SegMetrics we looked at Capistrano. One of the major benefits of Capistrano for me was the zero-downtime deploys. Since Capistrano builds the release in a separate folder and then symlinks the directory when done, there’s an almost zero downtime from the view of the user (the one gotcha is that PHP-FPM needs to be restarted to recognize the changed symlink, otherwise it will be pointing at the old data).

For our CI and testing we use CodeShip, which runs all our tests, and then if a test passes on our production branch, it runs Capistrano for us and pushes it all to live. It has been amazingly useful and makes it easy to know what gets pushed when, as well as getting everyone to sign off on a new feature before it goes live.

Checkout & Subscriptions

Stripe. Nuff said. If you’re not using Stripe, you need to start. At this point in the game there no reason to NOT use them, unless you’re in a country that doesn’t support them, and you can’t set up a U.S. business bank account.

Marketing Services

Now we get into the fun marketing stuff. Marketing tools are the sandbox that I play in all day long, so I am definitely predisposed to certain systems over others. However, I also wanted to keep in mind the fact that we were not going to take off doing $20k MRR right out of the gate, so larger and more expensive systems were going to have to wait till later. We chose our first systems to be ones that provide high value at low cost and can scale up quickly as the business grows.

Email Marketing

The basis of any good internet product is email. Email is the most effective way to communicate with your customers and lifecycle emails are a powerful tool for displaying the value of your product to users — especially during their trial period. For Summit Evergreen, we use Drip to power our automation and lifecycle email campaigns. Drip is really powerful and is great if you have a number of educational funnels or pre-warming funnels for your product.

For SegMetrics, we aren’t planning on doing more than one pre-customer funnel. Most of our emails will be lifecycle or transactional emails. While Drip is great for transactional emails as well, I wanted to play with Customer.IO, which is a tool that I’ve used with a number of my clients but never used on any of my internal projects.

We set up a quick lifecycle email funnel for new customers — essentially a “hi” email, a second email talking about some of the cool things you can do with SegMetrics, and finally an email towards the end of their trial asking for feedback on SegMetrics. (Shortly after we set them up, Baremetrics released their list of LifeCycle emails. Highly recommended reading.)

We’ll be building out that lifecycle email funnel more later based on a lot of the strategies from Patrick McKenzie’s LifeCycle Email Course.

The Data Collectors

While we don’t yet have the traffic numbers that ANYone should be jealous of, we have had enough traffic to learn some specific things about our users, and also where we should be marketing with PPC advertising.

We’re using a very standard marketing tracking strategy, and our Google Tag Manager is loaded with:

• Perfect Audience — No reason not to sign up at first. Tracking is free, and it’ll be ready when you want to run re-targeting campaigns later.
• Twitter & Facebook tracking — Also make sure you have those OG and CARD tags in the header, so you can customize what FB and Twitter displays when you put your link up.
• Google Analytics — Duh.
• Webmaster Tools — This is one that a lot of people forget about, but is one of the best ways to find broken links, search results, etc. It also connects straight into Google Analytics, so you can compare your data all from within a single interface
• Customer.io — As talked about above

Also, one recommendation — sign up and install the code for Perfect Audience at the beginning. You need a certain number of visitors before you can start retargeting, and it’s better to just have that counting from the beginning instead of having to start from scratch later on.

Advertising

Our advertising has been very brief but effective so far. We’ve been on Product Hunt, Hacker News, posted on twitter and a couple of other places. Product Hunt and direct traffic are by far our largest traffic sources so far, resulting in about 450 people on our first day.

Facebook traffic has also been very effective. Since our target market are people who use Infusionsoft, we’ve been able to target our advertisements directly to people who like Infusionsoft. There is one gotcha that I’ve never liked with Facebook ads, though: All clicks costs you money, which means you’re also paying for likes. Likes are a completely internal metric for Facebook (as they’re liking the PAGE, not the SITE), and it feels like I’m paying money to increase my HN karma score, or some similarly abstract number that does not move my business forward.

That’s just how Facebook ads work through, so if you want to play in their ad space (and believe me, you DO want to play there) then that’s one of the things that you have to put up with. Overall we’ve been very happy with the Facebook ads, and through better targeting we’ve been able to increase our CTR immensely.

Marketing Process

To be honest, we’re still in the middle of our marketing process. One thing we should have done — if not for the quick build time — was create a landing page and publish on places like Beta List. If we were to do it again, I would definitely stand up a quick landing page with something like LeadPages, promote it on Beta List, and have some sort of marketing funnel run while we were building.

We jumped the gun a little and didn’t do that, so we started marketing about 1 week into development when we stood up the beta version. Our marketing was low-key at first — we posted on Hacker News (no upvote love), twitter, Product Hunt and our own inner circles. First foray into marketing got us about 450 uniques in the first day, 3 emails from people interested in the product and a lot of extra buzz.

Our second (real) phase of marketing is PPC. As we have a very specific target market (people using Infusionsoft) it’s very easy to do targeted advertising on Facebook. (Interestingly enough, there are TWO interests you can target on Facebook for Infusionsoft. One with a capital “I” and one with a lowercase “i”. The one with the capital “I” has generated a 5X CTR (and much less “like spam” in case you’re looking to target Infusionsoft users yourself)

One other piece of marketing that we’re going to be doing is going to iCon — the Infusionsoft conference. In addition to gaining views and signups, the Facebook advertising is giving us a lot of face-time with people who are already using Infusionsoft, which will hopefully translate into people knowing who we are when we head to Phoenix next month.

As my co-founder Charlie can attest to, I am incredibly impatient. I like to dive in and get things done. Since this is a new product, we have a ton of marketing points that we can hit at once, but there is definitely value in not doing that. If we grow too quickly, we’ll be swept up in the momentum of new users and get lots of great feedback — but also be in fire-fighting mode as we scramble to get aspects of the software up and running that aren’t quite ready yet. And as anyone who has done development in fire-fighting mode will tell you, you don’t always make the best long-term decisions when you’re scrambling against the clock.

That being said, we have a number of strategies that we’re looking at for next steps:

• Getting our beta users and friends to refer us to others
• Talking with Infusionsoft users at iCon
• Setting up meetings with marketing agencies who use Infusionsoft
• Sending personal emails to marketers who use Infusionsoft (BuiltWith tells us that there are over 34,000 of them) and see if they’d be interested in the service

As an aside, laying out our marketing plan somehow feels like I’m sharing our secret sauce — like this is something that I should keep bottled up. But the fact of the matter is that the 4 items above, as well as what we did for advertising, are par for the course. They’re not secrets — they’re what anyone who is launching a product should be doing. Which is:

1. Find where your target market congregates and talk to them
2. Send personal emails to movers and shakers in your target market
3. Advertise to people in your target market

That’s all we’re doing, but somehow this part of the process feels like black magic to so many people. “You mean I have to go out and actually SELL this? What happened to Field of Dreams ‘Build it and they will come?’ “

Unfortunately there is no magic button that you can push to “get customers.” Well, there is, but it takes a lot of trial and error to find out what that magic button is for YOUR company.

Our Complete Timeline

Whew — so that was a long one. Here’s our complete timeline for the development process of SegMetrics.

Jan 13 — Our first talk about SegMetrics

Jan 15 — Finished version 1 of the data analysis engine, which gave us something like this:

* #of Leads 7634
* # of Buyers 161
* Conversion Rate 2.11%
* # of Sales 168
* $ Revenue $ 33314.50
* Lead Value ( Revenue / # Leads) $ 4.36
* Buyer Value (Revenue / # Buyers) $ 206.92
* AOV (Revenue / # of Sales) $ 198.3

(Note that most of these numbers were calculated WRONG, and it took 22 minutes to run the script to generate them, but it was good at proving value to beta users)

Jan 23 — After being really busy with consulting work, put together some quick wireframes in LucidCharts

Jan 28 — Decided to start the clock and got our two developers up to speed on the project.

Jan 28 — Built the Graphing and data parsing queries

Jan 29 — Added multi-tenancy and account, signup, authentication & user management functions

Jan 30 — Rebuild the Infusionsoft Gateway to be more flexible, added all the frontend UI, charts, asset files and misc screens

Jan 31 — Set up Capistrano, staging and production servers

— Started showing live data to beta users —

Feb 01 — Designed the top page, added in privacy policy and other items

Feb 02 — Install SSL Cert, final testing, turn Stripe to live

— Took a break to be with the family —

Feb 04 — Posted on Twitter & Hacker News

Everything since then has been marketing systems, copy tweaks and bug fixes as they come up.

Since launch we’ve added the following features:

• 30/60/90 Day Lifetime Value of Leads
• List of Products purchased for a segment
• Calculating change over time
• Lifecycle email funnel
• Help tags and instructions on the “getting started” pages
• A blog (yay!)
• IronMQ for running our data-getters — used to be manually run by a cron job
• LOTS of tweaks to our data algorithms

Each of these features is great to have, and improves the quality of the product, but NONE of them are a show-stopper for launching. We can, and DID, launch without these features — which is absolutely fine.

I had ulterior motives for some of the development, otherwise I would have also put off:

• Capistrano deploy — SSH + Git would have been fine
• Upgrade/Downgrade Accounts — No reason to have this in the first week
• Limits on Accounts — Actually, we STILL don’t have this. It’s all manual *shhhh*

Conclusion

Launching SegMetrics was a challenge both from a time perspective and because it forced us to really decide which features were a NEED and which were merely nice to have. So many people, myself included, get stuck trying to do things the RIGHT way, and obsessing over HOW to do something rather than actually going out and doing it. The number of hours I’ve spent comparing software solutions, frameworks, the perfect clipart to use, etc is time I will never get back — and time that I could have been shipping and iterating.

And as much as I tell this same thing to all my clients, when it’s your project — your baby — you get those same blinders on, and suddenly you’re there in the weeds, searching and re-searching instead of actually building and shipping.

Steve Jobs famously said “Real Artists Ship.” And while now almost a trite phrase, it is completely true. No one will ever see your work if you don’t ship it. And the only way to ship something is to actually get up and do it.

So, just like Nathan Barry’s 24-hour challenge, I challenge you.

I challenge you to take your idea, and to launch a half-baked, half-cocked idea in a week, and see what it feels like to get something out the door, instead of being that half-finished project that you’ll release “some day.”

— Keith
CTO & Co-Founder, SegMetrics.io

P.S. Interestingly enough, this project has inspired the rest of DelfiNet to get their projects out the door as well. Personal projects that have been sitting around for MONTHS are now out the door, and getting feedback from real users.

Isn’t that just the coolest thing you’ve heard?

This article was originally posted on http://delfi-net.com/how-we-launched-our-saas-in-1-week

Looking for more SaaS-building and marketing strategies? Register for the DelfiNet Monthly Marketing Newsletter.

SegMetrics DataSheet:

The 5 Second Pitch
SegMetrics is to Infusionsoft what Baremetrics is to Stripe — delivering clear, powerful analytics for Infusionsoft users so that they can understand what drives their business and make better decisions faster.

Description
SegMetrics gives you instant access to the most important metrics of your online business.

It lets you understand your business at a glance and start spending your time and money on leads most likely to convert.

Quickly see:

1. Which Affiliates and Ads are generating the most leads and money
2. Which Campaigns and Follow Up Sequences have the highest conversion rates
3. How long it takes to turn a Prospect into a Buyer

The Problems it Solves
Infusionsoft is great for segmenting and marketing but it doesn’t give you access to the metrics you need to make smart choices about your business. SegMetrics gives you instant access to metrics such as Lead Growth, Total Revenue, Average Order Value and Lead Value for each of your key marketing segments — as well as the overall lifetime value of your leads.

Without knowing how much a particular type of lead will be worth to you, it’s impossible to know how much you should spend to acquire more leads. If you don’t know how profitable each affiliate is, you won’t know which affiliate webinars you should prioritize. Sure you can know the immediate returns of automated funnels and webinars, but what about the values of leads 30, 60 or 90 days down the road? How much are leads worth AFTER the initial funnel?

These are the answers you get from SegMetrics INSTANTLY when you connect to your Infusionsoft account.

Get the right answers, in seconds, with SegMetrics.

Get started today, for free: https://segmetrics.io/