When I started writing Starting + Sustaining, payment processing was the most daunting topic. I felt that I had a cursory understanding of it all, but that turned out to be wrong. It is without a doubt the chapter that required the most effort to both research and write. As the longest and most involved chapter, it could be helpful to countless folks looking to launch their app. As such, I’m giving it away for anyone that could use it.

If you have any questions about payment processing, providers, merchant accounts, PCI compliance, or any of that stuff, this chapter should really help you jumpstart your learning. I hope it helps.

Download the free payment processing chapter from Starting + Sustaining

If you’re building a company as a solo founder, you have a long lonely road ahead of you. The sooner you start putting together a team, the better off you’ll be in every possible way.

I originally made the mistake of believing that it didn’t make sense to pull in contractors on a regular basis because of the amount of time it would take for them to ramp up on Sifter. Instead, I set my sights on getting us to the point where we could hire full-time help. In theory, that way we’d have someone involved who didn’t have to constantly be ramped up.

I couldn’t have been more wrong. These days, we effectively have a bookkeeper, system administrator, front-end developer, and two Rails developers on retainer. Each month, depending on their availability and Sifter’s needs each of them work somewhere between 2-30 hours per month. On top of this, we’re also outsourcing some marketing work so that I can stay more focused on the product. We should have done this a long time ago.

This may not sound like a lot of hours, but these team members have two huge advantages over founders. First, they aren’t multi-tasking and context-switching like founders have to. So they’re able to focus on and execute much more efficiently. Second, and most important, they’re experts at what they do. As a founder, you have to be a generalist, it’s impossible for you to as good at any of their tasks as they are. If you find the right people, they’ll do a better job within their area of expertise than you ever could, and they’ll be faster.

On top of that, there’s one big intangible reason. Working with a team of people makes work more fun. While this probably isn’t news to anyone who’s ever been in this situation, I doubt that I’m alone in being hesitant to bring on contractors for fear of using all of their time ramping them up on a new codebase. It’s not true at all. Find people that can help you 10-20 hours per month and setup a retainer with them. The sooner you begin to build a team, even if they’re only a part-time team, the better off you’ll be.

Three months after deciding to write a book about building, launching, and maintaining a web application, the progress is good. I’d like to be further along, but took a break from writing to spend some time on Sifter. So where are things at and what have I learned about self-publishing an eBook?

First and foremost, the logistics took a lot of time. Planning the content, understanding the world of digital publishing, settling on a good workflow for both the writing and editing, as well as choosing the right tools all took quite a bit more time than I would have liked. Thankfully that’s all behind us now.

PDF, epub, etc.

The first thing I wanted to work out was how the whole process would work. I didn’t want to write in one format/tool only to have to later go through and manually edit everything to put it into the final format. Similarly, I wanted to make sure that the process worked well for our editor and the various other people providing feedback. Long-story short, given limited resources and the goal of having a lot of graphs and visualizations, I wanted to keep everything as simple as possible, and we settled on publishing only a PDF.

Workflow

Since we’re only doing a PDF, I chose to put everything together in iBooks Author. Given that decision and the usefulness of tracking changes in Pages, I’m writing everything in Pages and storing it all in Dropbox for easy sharing with the editor and various others providing feedback.

As the files are updated, we simply update the file name with “(Assignee Name)” at the end. The beginning of each file name is in a “#.#” format where the first number indicates the section and the second indicates the chapter/topic within that section. So each file looks something like “1.2 Topic Name (Assignee Name)”. This makes it easy enough to reorganize content without involving too many different applications.

With all of this, the only challenge has been that Keith, my business partner, is a Windows user and can’t easily edit Pages documents. Fortunately, he’s providing higher level feedback, so this hasn’t been a significant problem.

Planning the Content

One of the most challenging parts was narrowing down the scope. In some cases, each of these topics could be 10,000 words by themselves. The way that I narrowed it down was to focus purely on logistics. While I mention technical bits that need to be in your plan, I’m primarily focusing on things that need to be done, things that are easily overlooked, or things that are tempting to cut out.

While I expect it to evolve a bit, the book is primarily broken up into 4 sections of 9 topics each. Each topic is about 900-1,200 words. Fortunately, now that this is about 90% locked down, the writing has been flowing nicely.

The Research

With the book, I want to share a lot of the data that I’ve used to make some of our decisions over the years. This has required doing a fair amount of legwork and writing a few more SQL queries than I would prefer, but fortunately it’s all done. I’ve been swimming in data, and found some really interesting things to discuss.

The Spreadsheet

Originally, I wasn’t sure if I wanted to do more than a book, but as I started writing, I realized that much of our decision making is an extension of the information that we have in a rather complex spreadsheet that I update monthly. So, I spent a few days and redesigned and rebuilt the spreadsheet from scratch so that it would be easy to use and compliment the book.

The goal of the spreadsheet is to help get a clearer grasp of the costs of starting and running a web application. It can help make the numbers very real and let you quickly adjust numbers to understand the impact of charging $9 a month or $29 a month. Honestly, I might argue that the spreadsheet is almost as helpful as the book itself. They’re a team, though, and the spreadsheet should really help anyone who’s trying to put together a budget.

The Vendor List

In addition to the spreadsheet, I’m also compiling a vendor list for the wide variety of services that one would need to enlist in order to build a web application. Hosting. Transactional email. Help desk. Domains. DNS. Continuous integration. Email newsletters. Log monitoring. Performance monitoring. Uptime monitoring. Source control. Team communication. And more. I’m not going to review any of the products, but the list should definitely make it easier to quickly narrow down which tools are best for a given team’s needs.

The Writing

This is where I’m spending my time these days. The book is about 25% complete, including editing. I expect to finish all of the writing this week, and then it’s off for feedback and editing. Once that’s complete and all of the content is laid out, I’ll be passing it along to a handful of other folks who’ve launched their own applications in order to get some final feedback and additional perspective. Then I’ll incorporate their suggestions and it’s just a matter of picking a day and finishing propping up the store.

Due Date

I’m not sure exactly when it will be ready, but I can say that I’ll be wildly disappointed if it’s not available by the end of March. I’m racing to get it out long before that, but that’s my current drop-dead date. My main concern is that I want to allow the reviewers plenty of time to read it and share their feedback.

Some Random Thoughts

As I progress on the book, I’m more and more excited to get it out there. It’s not rocket science, but I constantly imagine myself five years ago and wish desperately that I could have had access to all of this information rather than just figuring it out as I went along.

I truly believe that this information would have saved me at least a month’s worth of development effort if not more. It would probably have also saved me about two weeks worth of research. The spreadsheet alone incorporates several years of acquired knowledge that should make it dramatically easier to plan your finances or at least make a much more educated guess.

Ultimately, I’m really excited to help people get better products out the door in a shorter period of time with a whole lot fewer mistakes and less pain. I figure the sooner it’s available, the sooner others can begin benefitting from all of these lessons.

It seems like many stories about quitting a job are dramatic and quick. i.e. “I had finally had enough and just quit.” It doesn’t need to be that way, and it’s probably easier if it’s not. Instead of thinking about giving your employer two weeks notice, think of it as giving yourself two years notice.

When I left my job to start Sifter, I had been preparing for it for about two years. I wasn’t unhappy with my work, and I never had a date in my head. However, I knew that at some point I was going to want to do my own thing. As a result, I spent about two years consciously molding my life to make it easier for me to go out on my own.

I paid off my credit card debt and began saving as much as I could. I moved out of an apartment with roommates into a tiny shoebox of an apartment so I could more easily work at night and on weekends. This increased my costs slightly but drastically decreased my distractions.

Then, on a whim, I started designing a bug tracker for fun with no idea of where it was really going to go. I was primarily looking for tangible things that I could use to discuss interface design without having it be covered by an NDA like everything from the day job. Maybe I’d develop it and open source it, or maybe it would never be anything more than comps. Those designs turned into some material for presentations about interface design, and those presentations generated the interest for my business parter to convince me to start a business.

I had started designing those comps in August of 2007. A few months later in January, I was starting to work on Sifter full-time. However, if I hadn’t paid off my debt and started saving, I wouldn’t have been financially able to take a paycut. If I hadn’t gotten my own apartment, I would have never found time to work on things in my free-time. If I hadn’t started designing for fun in my free-time, I would have never shown anyone the ideas floating around in my head. I had been taking steps to prepare myself for years without knowing exactly where they would lead. I only knew that they were the right steps.

You don’t need to dream about quitting and just waiting until you just can’t take it anymore. Instead, just start doing the things that will enable you to quit someday. You don’t need to have a specific plan or date in mind, but if you start preparing today, you’ll be much better positioned to make a change when you’re ready for it or when an opportunity presents itself.

At some point, we’ve all faced it. Do we rebuild from scratch or simply refactor? With personal sites, it seems the rebuild is the default option. We see an archaic mess of code and a design that’s atrocious. So we rebuild. With a web application, that’s not always a good idea. This is a decision where it’s incredibly important not to let emotion get the best of you.

If your application is successful and profitable, a rewrite is riskier than refactoring. However, if your application hasn’t seen any significant adoption or is otherwise stagnating, a rewrite may be just what you need to breathe new life into it. Based on my experience, here’s a short list of pros and cons for rebuilding and refactoring.

Rebuilding

+ Start Clean. It seems glamorous, but it’s not necessarily a business reason. This is often more of an emotional belief that it will be better this time.

- Stagnation and long release cycle. With a complete rebuild, it’s easy for the application to appear to be stagnating even though you’re working vigorously on the new code. So now, not only do you have to catch up to your previous feature set, but you need to release something that’s a significant improvement. Otherwise, you’ve invested a lot of time in what customers would perceive as an equivalent product.

- User Revolt Changing anything dramatically in one fell swoop will invariably upset some of your customers. That can become a distraction in and of itself. I see these even when we make small focused changes, so I can only imagine what a complete rewrite would do.

- Risk of Major Bugs It introduces a lot of opportunity for bigger mistakes. Launches aren’t easy, and when you already have a significant user base, it’s nearly impossible to catch all of the edge cases prior to launching. That can lead to disappointed customers as well.

- Temptation/Scope Creep Starting from scratch makes it much easier to get distracted with shiny new tech and potential features. Building something from scratch provides very little in terms of a framework for managing scope. When the road is wide open, it’s more difficult to stay focused.

- Internally motivated vs. externally motivated. Rewrites are usually internally motivated because customers don’t see the cruft. So it’s usually the development team that wants to start over. It’s important to ask how a rewrite will directly benefit customers? If it’s not direct, then it may not be the right move.

- Discipline While you will always enter a rewrite with more knowledge and experience, writing good code requires discipline. In my opinion, refactoring is the best way to create that discipline. It’s much easier to become consistent and see repeatable results in small bits at a time. Similarly, I’ve found that it helps to look at “bad” code and learn ways to improve it. Doing a major rewrite introduces too much temptation to cut corners.

Refactoring

- Slower overall. It takes a while to start seeing meaningful results. It’s almost a leap of faith that over time things will improve meaningfully.

+ Faster cycles. With a rebuild, there’s no quick wins, but with refactoring, you can constantly be releasing updates. This helps keep morale high and also enables you to ensure your customers are regularly seeing improvements and other benefits of your work.

+ Safe. Small chunks mean minimal risk with each subsequent update. There may be bugs, but they’ll be isolated and you can quickly dive in and fix them as they’re released.

+ Repeatable. It becomes a habit, but like any habit, it takes practice. Since refactoring is about taking bite size chunks and improving them, it’s easier for it to become a habit than trying to build it from scratch.

+ Balanced with features. With refactoring, you can spend a couple of weeks behind the scenes. Then a couple of weeks on customer features. This helps alleviate any perception of a stagnant product when you’re spending time on things that customers won’t see.

+ Learning. I believe that I’ve learned more about writing good code by seeing what I did wrong and forcing myself to find/learn a better way than I would have if I had just thrown it away and started from scratch.

Recommendation

Unless there are clear business benefits like migrating to a newer technology stack that will provide more agility, increase the potential talent pool to grow your team, or simply enable you to do things that were impossible with your previous stack, I personally don’t think rewrites are the best approach. If you’re not planning on changing your technology stack, I believe you’re much better off making gradual and consistent improvements and learning as you go.

I’ve found that the best way to guide refactoring is to find the right tools to help you identify the spots that need the most attention. We’ve come to rely on two tools to help us do this. New Relic helps us identify areas that need improvement for direct customer benefit in areas like performance and reliability, and Code Climate (Ruby only) helps us identify the code smells that we should clean up so that we can make enhancements more quickly and with less risk.

I’d strongly suggest using these or other similar tools to act as an angel on your shoulder. They’ll help you identify the most important places to start and keep you focused on the right things. Regardless, I’d generally advise to be quick to refactor but slow to rebuild.

P.S. If you enjoyed this, you might like my upcoming eBook, Starting + Sustaining about bootstrapping your own web application.

Prior to Sifter, I was a specialist. I needed to keep up with two or three high-level topics in order to stay current and not be left behind. I had a few RSS subscriptions and kept up with a few topics on Twitter. It wasn’t easy, but wasn’t impossible either. Life was simpler then.

Since starting Sifter, I’ve tried to stay current on every piece of our business from the complete technology stack to the business and marketing side of things. As a solo founder, keeping up with everything that I need to create the best possible product for our customers is truly impossible if I also want to build anything.

Let’s just look at front-end development. HTML5, CSS3, animation, transitions, SASS, Compass, LESS, CoffeeScript, jQuery, Ajax, web fonts, HiDPI displays and Responsive design, a proliferation of devices, screen sizes, and resolutions unlike anything we’ve ever seen. That’s a full-time job right there. As a related aside, when Sifter launched, it only had about 50 lines of JavaScript. It simply wasn’t feasible for me to build the application and add all of the advanced interaction that was starting to appear. JavaScript wasn’t a strength of mine, so I focused elsewhere.

It’s easy to get swept up in staying current and forget that the whole point is to create something. These days, I’ve accepted that’s a bad idea. Instead of trying to know everything, I focus on simply staying aware of what’s happening. Then, when the time is right and the advances might be useful, I can set aside time to learn.

As a solo founder, time is limited. You don’t want to be left behind, but you don’t want to spend all of your time keep up either. Prior to starting Sifter, I used to believe that running my own business would give me flexibility to aimlessly explore new technologies. I was half right. There’s plenty of time to use and learn the technology, but there’s not much room for aimless exploration.

When you need to learn something, take the time and do it right, but if you don’t need it yet, file it away and move on. Worse case scenario: it will be there you when you need it. Best case scenario: newer technology will make it obsolete and 10 times easier by the time you do need it.

In order to fully commit your attention to building something that isn’t yet making money, you can either work more hours, or get by on less income. The former isn’t healthy or sustainable, and the latter isn’t easy.

When you have the golden handcuffs of a large regular paycheck accompanied by health insurance and other benefits, it’s hard to imagine living on less income. It’s rare that people actually quantify the effect that starting a business can, and likely will, have on one’s income in the short-term. So, to help put things in perspective, here are real numbers from my tax returns before and after.

In 2007, I made $86,978 and had a full suite of benefits. My income came out to around $71,417 after taxes. January 1st, 2008, I quit my job to focus my efforts on Sifter knowing that I could freelance to make money when I needed to. In 2008, the year that I built and launched Sifter, I made $36,124 and had no benefits. After taxes, I made about $24,832.

My first year after quitting my job, I made 41.5% of my previous income. If you factor in self-employment taxes and look at take-home income, I brought in 34.7% of what my previous salary was. That’s a lot of Ramen noodles.

The only way that was possible for me was by being debt free, saving up prior to leaving my job and cutting my personal expenses. I could have always made more money by doing more freelancing, but that would have taken time away from building Sifter. At the time, I wasn’t married, didn’t have kids, and didn’t have a mortgage, but all of those followed shortly thereafter.

Everyone has their own scenario and own challenges, but I’ve found that quantifying these things paints a sobering picture of “bootstrapping startup life”. My guess is that the reason that many people raise venture capital is precisely because of this fact. They simply can’t afford to take a pay cut. It certainly used to cross my mind.

If you want to start a business, the most important thing to recognize financially is that you are your biggest cost. Your car payment. Your mortgage. Your family. Your lifestyle. Your unsecured debt. Your savings. The easier it is for you to survive on less income, the less stressful your journey will be. It means fewer distractions, more time to build your product and generally a more pleasant trip.

Save. Delay quitting your job as long as possible. Cancel cable. Sell your TV. Sell your car and drive something cheaper. If you’re really extreme, downgrade your home or even move to an area with a lower cost of living. It’s not easy, but it’s an option. Ruthlessly trimming your personal expenses is just as important as ruthlessly trimming your business expenses. When you’re bootstrapping, they’re one and the same.

P.S. If you enjoyed this, you might like my upcoming eBook, Starting + Sustaining about bootstrapping your own web application.

One of the most frustrating tradeoffs during these years that I’ve been working on Sifter has been the degree to which I’ve cut some corners with user experience. It wasn’t a decision that I took lightly, but it was a very deliberate decision. Now that I feel like we’re finally beginning to move towards the level of quality that I would like, I’m comfortable sharing this.

For almost four years now, I’ve been using a tool that I love but that drives me crazy. A rough edge here, a sharp corner there, and a lack of general cohesiveness throughout. It’s been driving me nuts. Every day, I saw things and knew about things I wanted to fix, but every day I forced myself to look the other way and focus on the bigger picture.

You see, up until recently, the only real goal has been shipping. I strive to take great care of our existing customers first and then to get improvements out to them second. Like a cloud looming over me, I felt like we were constantly failing to quickly get key features into customer hands. If it worked reliably but maybe felt a big clunky in areas, I was ok with that in order to get it to our customers. In some cases it was a great strategy because we could then use feedback from customers to really get it right.

When there’s really only one person doing design, front-end development, back-end development, support, marketing, and a variety of other tasks, something has to give. Now, things are far from perfect, but now that I feel like we’re regularly making meaningful progress, I’m indulging myself and fixing up some of those annoying little bits. There’s still an absurd amount of work left to do, but if you’re a Sifter user, hopefully you notice extra attention the little things are receiving these days.

There was a probably an easier way. Fortunately, it feels like we’re over the hump. Regardless, being a solo founder probably isn’t for everyone. I imagine it’s something like being a single parent. It’s not impossible, but it’s no cake walk. There’s really no such thing as “days off”. Some days are thrilling, and others are gut-wrenching. In the end, it’s worth it. Not easy. But worth it.

I should qualify what I’m calling being a “solo” founder. In the most technical sense of the word, I’m not a solo founder. I’ve had a fair amount of help. I’ve never had to really deal with our taxes, legal, or insurance matters. I’m involved with them but not responsible. Keith Jacobs, my business partner, handles most of that. However, for about four years now, I’ve been the only person in the trenches every day. Holidays. Weekends. It’s all a blur now, but if something went wrong or someone needed help, I was the one handling it. Even vacations weren’t really vacations.

Ironically, these days vacations are actually more stressful than being at home. Being out of town and away from the computer, I’m constantly aware of whether my devices are charged and how far I am from a reliable internet connection. I always keep a close eye on whether I have cell phone service. These things dominated my thoughts when I was out of town. I had stopped enjoying my time away because I was always worrying. That’s changed these days because even the worst days weren’t all that bad, and now I know that I can handle it.

Scheming & Jumping

The journey is likely the most interesting part. So lets start from the beginning. I had been scheming of ways to build Sifter since 2003. I was always sketching and wireframing ideas in my free time. From time to time, Keith and I would sit down with a spreadsheet and make up numbers about whether we could pull it off. However, with a consulting company of 20 to support, we never had the guts to try and make the transition happen. It wasn’t until 2008 until it became realistic, albeit under completely different circumstances.

Around the end of 2007, I had decided to just go ahead and build my little issue tracker for fun. I started tossing out some ideas on my blog, and before I knew it, some friends were encouraging me to try and build a business out of it all. Keith put up enough money to cover the cost of incorporating and few of other inevitable startup expenses, and I quit my job.

I had just recently paid off all of my credit cards. So, with about three months worth of financial cushion from my personal savings and impending freelance work, I could spend my extra time creating Sifter. It took eleven months working part-time on Sifter to design build and launch. I worked more than a few weekends, skipped out on some nice weather days at the lake and eventually finished development. During that time, I continued sharing my progress on our blog, and we built a modest following. By the time the launch rolled around, around 1,000 people had expressed an interest in Sifter.

We launched in December of 2008. By the end of the first month, we were bringing in $1,000 monthly and covering all of our expenses with just enough left over each month to put aside money for a rainy day. Now at this point, I wasn’t getting paid, but I was entirely responsible for a business that was expected to be open and available 24 hours a day and 7 days a week. Managing that and still working part-time to pay my bills is where things became hectic.

Balancing it All

The time period between launching and supporting me full-time was without a doubt the most challenging and exhausting experience of my life. Managing the application on top of a full or even part-time job isn’t impossible, but it’s not easy. Fortunately, there’s something exciting about working towards something that you care deeply about. It stopped feeling like work, and it just become a really long journey where every day was completely unpredictable.

It was during this time that I constantly questioned whether I was doing the right thing. I regularly turned to close friends about whether I had it in me or whether we should hire someone else to handle all of the day-to-day stuff while I got a normal job again. I explored all sorts of possible options looking for the approach that would yield the best results for our customers while ensuring that I didn’t go crazy.

The really challenging part was the constant struggle to maintain a healthy balance between work and life. In a past life, I completely neglected that balance, and it didn’t work. It makes things really easy in the short-term, but I’ve never found it to work well long-term. This time around, I made a simple promise to myself. I wasn’t going to let the business get in the way of living, and I definitely stayed true to that.

During an eighteen month period before Sifter was supporting me full-time, I moved, got engaged, planned a wedding and a honeymoon, got married, went on the honeymoon, got a puppy, bought a house, and then moved again into the new house. That’s in addition to launching and supporting Sifter while having a full-time job during half that time and a part-time job during the other half. Not too long after all that, my wife and were expecting our first child.

At every step of the way, there was a nagging feeling that I couldn’t take any of those steps until Sifter could support me full-time, but that would have meant putting everything on hold for at least a year, maybe two. Looking back now, that would have been the real mistake.

Lauren, my wife, has become a co-founder of sorts. She’s the one that has to put up with me checking email and responding to support requests in the middle of the night. When I’m driving, she regularly reads support emails to me and then types as I dictate the response to her. I give her a hard time about supporting me at times, but she’s played a significant role in enabling me to create Sifter.

She deals with the financial, emotional, and physical ups and downs of me pouring myself into something with no guarantee of success. She’s essentially going based on a promise that it won’t be this way forever. As someone who barely uses, and doesn’t really understand technology, she has placed a lot of faith in my promises despite how long of a journey it’s been.

Problems Don’t Wait for a Convenient Time

As if balancing everything day-to-day wasn’t enough, there’s always the occasional fire to put out as well. One afternoon, I discovered that someone was using our credit card processing to validate stolen credit card numbers. The individual was able to run a over a hundred card numbers before we were able to get some controls in place. With transaction fees, that came out to a couple of hundred dollars out of our pocket. Not much in the grand scheme of things, but the distraction of dealing with the fraud took its toll on my development time.

The next couple of weeks were a cat and mouse game where we locked it down a little more every few days as needed. We didn’t want to go all out and adversely affect legitimate customers, so we tightend it gradually. It wasn’t directly affecting our customers, so we didn’t want to let it get to the point where it would. It was just an ongoing distraction. One night during all of this, I was a groomsman in a friend’s wedding. The ceremony had just ended and the reception was about to start when the notifications started arriving. Ten more attempts by the fraudster.

It really wasn’t a big deal, but I let it ruin my night. At this point, I realized I’d have to go all out to lock it down, and I spent the rest of the night thinking through all of our options. Physically, I was still present, but mentally, I had completely checked out. That became a turning point for me. I recognized that things could and would go wrong at inconvenient times, but it was never anything that couldn’t be handled. These days, I generally do a better job of stepping back and deciding whether I need to respond immediately or if it can wait. If it can wait, I do my best to not let it bother me in the meantime. That’s easier said than done, though.

At first, being perpetually on call was stressful. I could have to drop everything and work at any moment, but I could also work anywhere, at any time, and any way that I desired. If I work a twelve hour day one day, I can pack it in early on the next. Once I learned to embrace the chaos, things changed dramatically. It was amazing.

These days, I wake up in the middle of night to answer support emails from customers around the world, and it’s actually kind of fun. Everyone tells me that it’s not necessary or healthy, but I’ve found that it works. Whether I work at 2am or 2pm, it really doesn’t matter. Learning to just go with the flow and adapt has literally changed everything. Now every day is an adventure, and it works. The only hard part is finding longer uninterrupted blocks of time for design and development.

The Full-time Milestone

After a tumultuous year of balancing outside work with Sifter, I finally decided that the only strategy that would save my sanity would be going full-time. That brought with it worries about health insurance combined with the fact that I’d need to take a 20% pay cut to make it work. Based on more recent offers, it turns out that it’s about a 40% paycut. The biggest lesson here was that learning to live below your means is a key enabler to starting a business.

This was the first time that money and financials became a concern. Had I been younger with fewer responsibilities, I probably wouldn’t have been thought twice about the risk. However our health insurance was dependent on my full-time employment and our mortgage wasn’t going anywhere. Combining a pay cut with paying for insurance and health care out of pocket makes for a pretty scary decision. It wasn’t made any easier by our thoughts of having our first child in the next year or so.

Once I was full-time, the next few months turned into one huge game of playing catchup. I had hoped that going full-time would be a dream come true, but all it meant was that I no longer had any distractions to take my mind off of just how much work I had to do. By early 2010, Sifter was in good shape, and we were wildly optimistic about the improvements that we had queued up. Then something completely took the wind out of my sails.

The Lowest Point

We had already begun talking about taking upgrading our infrastructure, and we were exploring the idea of moving hosts and improving our backups while simultaneously working on some significant improvements to the application. With the hopes of buying ourselves some time in order to delay the upgrades and tie up some loose ends, I decided to just upgrade up our virtual machine. I chose poorly.

The next morning when I was reviewing our performance, the increase hadn’t had much of an effect, and we made the decision to revert back to the original. At the time, all I was thinking about was the amount of downtime that it would cost us. A quick revert would just be a reboot, and we’d be down for less than a minute. Letting it ride and resizing downard later would mean 20-30 minutes of downtime. I chose the latter in order to minimize downtime. Within seconds of that decision, I realized it was a bad idea.

By reverting, we immediately lost all data that had been created on the new virtual machine overnight. It was about 11 hours worth. Fortunately, we were able to recover about 3 hours worth from our backups, but the remaining 8 hours of lost data during peak business hours for Europe still meant that some of our customers were seriously affected. I’ve never felt a sinking feeling like that before. My initial over-reaction was that our customers would leave in droves, and Sifter wouldn’t survive. Fortunately, that was far from the case.

We immediately went into recovery mode and were incredibly transparent about the mistake, the consequences, and our plans. We issued a month of credit to every affected customer and lost a fair amount of revenue as a result. I wasn’t concerned with the lost revenue, though. I was disappointed with myself. We have hundreds of customers and thousands of users that entrust their work to us, and I let them down. Over the next couple of days, I really learned just how wonderful and understanding customers can be. To the best of my knowledge, nobody cancelled as a direct result of the data loss, and most were very supportive.

Since then, we’ve dramatically improved our infrastructure. We have a dramatically improved backup system in place along with a much more scalable architecture. It was a painful lesson, but it’s a lesson that won’t be forgotten. More importantly, the result of the experience was that I’ve never been more excited or wanted to work harder for our customers. In the moment, it feels terrible, but we made it through. It’s true you know. What doesn’t kill you only makes you stronger.

These Days

Things have been much less dramatic in the last year. I’ve now been full-time for about two years, and we’re in a much better place both in terms of infrastructure and new development. I’d like to see us move a bit faster, but I also like growing at a stable rate. Fortunately, most of the behind-the-scenes work is done for a while. We can safely and quickly scale if we need to, we’re profitable, and we have some great improvements in the works.

If I had to, I’d definitely do it all over again, but if I could make one decision differently, we would have brought an additional developer on board as a founder from the beginning. Running a web app alone isn’t the best way to do things, but even under some of the most trying circumstances, it’s doable. Looking back at the last three years of working Sifter, I can honestly say that I’ve never been happier. It was a long road, but once I learned to enjoy the trip, it became much more enjoyable.

Lately I’ve been spending a lot of time in our garage making things by hand for my office. Admittedly, much of the stuff is purchased, and all I’m really doing is a little sawing, sanding, painting, finishing, and nailing. Assuming it’s not just the fumes talking, I’ve really enjoyed it. It’s also been a nice break from creating digital things.

Getting your hands dirty and working with physical tools is a completely different experience. It’s much easier to get caught up in the details and the craft. When you make mistakes while creating physical things, there’s no undo, so you’re more careful and every decision is more considered. You’re more likely to do some tests on scrap wood before touching the real project. Don’t get me wrong, I don’t believe that what I’ve done is really all that special, but the process has really made me think about how we create digital things.

When I’m sanding and finishing something, I take breaks in between each step to really analyze the results. I run my hands over it feeling for imperfections. I look at it from different angles to see if the light is reflecting evenly. I simply handle things more delicately. Moreover, many of the steps necessitate a waiting period afterwards. Stains need several hours to dry. Multiple coats can be applied and require more time. The amount of time spent waiting for things to dry is exponentially longer than the time you actually spend working.

With digital, none of this applies. But, it can. Imagine stopping between each step just to look at what you’ve created. Wrote some HTML? Spend a couple of hours just reading it. Don’t change anything right away, just read it and make mental notes. Then take the time to address those problems. Finished a comp? Just look at it. Soak in the details. Don’t write down notes. Just look for blemishes or imperfections.

With physical things, each step builds on the previous. If you don’t sand something smooth, the end result can’t possibly be smooth. If you don’t use wood conditioner on soft wood, the stain won’t apply evenly. It’s a layering process much like development. If you intentionally neglect details early on for the sake of speed, those will turn into larger and more obvious blemishes later in the process.

The goal of all this isn’t to compare physical and digital work, but to start looking at our practices in the physical world with similar practices in the digital world. It’s just a few of the thoughts bouncing around in my head lately.

I’m in love with this article about meetups to repair broken goods. Working on Sifter and pouring myself into it has bred a fascination with tools, manual labor, and vintage goods. Things used to be built for longevity. Design was simpler and more timeless. It was practical. It was possible to repair things.

These days, with more advanced technology and circuitry and the speed with which companies make improvements to their products, the cost of replacing something is generally lower than the cost of repairing it. Add to that the benefit of gaining new benefits from the upgrade, and we’re throwing away a lot of stuff.

It doesn’t have to be that way. Part of this is about sustainability. Part of it is about a return to working with our hands on something other than a keyboard, and, in this case, part of it is about community. These efforts are powerful and practical on so many levels that it’s hard not to fall in love with it.

We’re rolling out a new identity for Sifter, and while I couldn’t be happier with it, part of me worries about how superficial it may seem from the outside. Reading countless corporate-speak press releases over the years about new logos “synergizing and representing the cohesive nature of the profitable vision for the future” has made me jaded to such seemingly contrived drivel.

That said, while it’s meaningful to us, it’s really more of a drop in the bucket relative to what’s really happening with Sifter. We’re working like mad on several fronts. For those on the outside, Sifter probably seems like a barely evolving app, and until the last couple of months, that’s a very reasonable perception because we’ve been doing an incredible amount of operations work.

So, to an outsider, it’s just another silly logo change, but as an insider, I can definitely say that it’s much bigger than that. We’re picking up steam, and the way I see it, the current version of Sifter is simply funding the real version that I’ve always wanted to build. It’s enabling us to put the time and care into the details that we always wanted to. There won’t be a single moment that defines the “new” Sifter, though. It’s just going to continue being an evolution towards our now crystal clear internal vision of what Sifter should be.