Life at a tiny company
It's been a year since my cofounder and I let go of our team and buckled down to take on 2015 as a tiny, 2-person company. Turns out, 2015 had a lot in store for us: a couple high highs, a couple low lows, and a whole lot of just doing the work, grinding it out, one day after another. I'm proud of what we accomplished. I've never produced so much with so little. But for an ambitious company, the state of "tininess" is a special one: it's proud and independent, it's satisfying when it's not frustrating, and it's a lot of fun—when it's not driving you absolutely mad.
A tiny company is nimble. We were sitting in the last row at a presentation about ethics in data handling when I leaned over and whispered to my cofounder, "Remember that project you were talking about?"
"We should build it. Let's just build it."
He nodded. That's when the decision was made. A tiny company can make big moves fast. There isn't much research, many meetings or pitches or proposals, there aren't slide decks or whitepapers or lawyers or a prolonged stakeholder buy-in process. When you're half a tiny company there are only two people who get to decide, and in a single, quick exchange, you take the first step toward shipping a whole new product.
A tiny company doesn't have an office. Or meetings. Or HR. Or a vacation policy. Frankly, being half of a tiny company is kind of weird. It doesn't look very professional. This year, for me, it meant working in my basement office most days in my jeans and a tee-shirt and instant messaging with my cofounder till all hours of the night. It meant going out one or two days a week to meet up at a $10 per day rent-a-desk coworking space, or camping out at friends' offices. It meant constant, ambient chatting and almost no formal conference room meetings or inter-company email. We share a Slack account, Dropbox, calendar, and a GitHub account. You don't ask for a sick or personal day; when I needed to take a vacation, I said "Hey, I'll be offline these days. Take a look at these open tickets while I'm gone." There's no middle manager giving you side-eye if you show up to work late. There are no middle managers at all. You're both the bosses, the employees, and everything in between.
Sounds great, right?
It is, until you check your bank balance. Which you do, several times a month.
A tiny company has a poverty mindset. When you're a tiny company you're tiny because you're just making ends meet, and that means every dollar that comes in matters a lot, and every dollar that goes out has to have a really good reason to make an exit. There are no off-sites or catered lunches or open bars or Monday morning donuts or Friday afternoon drinks or company-provided dual monitors or health insurance or retirement funds or even company tee-shirts with your logo emblazoned on them. There's you, on your laptop, constantly tinkering with a spreadsheet, brainstorming ideas for revenue growth or expense cuts.
A tiny company gets set back easily. When you're a 2-person company, one person's sick kid staying home from school means the company is working at half-capacity. One unexpected task delays development on everything else. One payments API deprecation can put the entire company's revenue stream into danger. Going to a conference, a dentist appointment, getting stuck in a long line at the DMV—all these things can slow down the company's progress because it's only two of you moving things forward. And if you're both not moving things forward, the company is standing still.
A tiny company wings it. In my time running my tiny company, I've had to get good at an array of tasks, which all have dedicated professionals who do only these tasks all day long in large organizations. Nowhere else can you be a software company's sole developer and also get to work on copywriting, email marketing, project management, user experience design, customer service, user feedback response, billing, managing a profit and loss statement, and reviewing stupid amounts of legal paperwork. (Okay fine, I'll admit I hired a attorney to do that last one.) Company tininess means your specialties and deep expertise matter less than your ability to learn just enough of the skill you need that particular day to achieve the goal at hand. Figuring it out and getting the job done brings a special sense of satisfaction, tinged with a hope that someday, you'll be able to hire one of those dedicated professionals.
Life at a tiny company is exciting, and difficult, but most of all, it's educational. In the past 12 months I've learned more about myself as a working professional than I have in any other year of my career. If you're committed to independence, pride yourself on rolling up those sleeves and figuring it out, and enjoy having more control (if smaller impact), life at a tiny, 2-person company is a daily education in capitalism, creativity, and survival.
The Oxygen Mask
In one of my working mom groups, a common piece of advice is to "Put on your own oxygen mask first." Of course it's a reference to the airline emergency procedure speech we all hear before a flight takes off: "In the event of an emergency, please put your own oxygen mask on first before assisting others." In other words, you've got to take care of yourself before you can take care of anyone else.
Everyday life isn't an in-flight emergency. But when you've got a caregiver mindset and you're responsible for others, whether that's a small child, an ill parent, a fledgling startup, or a spouse going through a hard time, it's too easy to push aside your own self-care.
Last week, I found out just how dumb it is to delay putting on your oxygen mask.
About a year ago, I noticed that my allergies and asthma were acting a little worse, that I was wheezing and coughing more, that breathing didn't feel as easy. But being so busy renovating a house, running my company, and parenting, I put off going to the doctor for a long time. So long that last spring, I wound up in urgent care, hooked up to a breathing machine. I wrote off the episode as my "mild" asthma acting up because of construction dust.
Again, I let months go by until I scheduled a followup appointment with my doctor. After one conversation with her and a visit to my pharmacy, last week I got a new asthma medication. The first night, I took the tiny pill and went to sleep. When I woke up, I sat up in bed and took the deepest breath I had in over a year. I hadn't felt my lungs expand that much without exploding into a coughing fit in forever. I kept taking deep breath after deep breath. I felt like a new person.
I finally reached for my oxygen mask after gasping for breath for months. Months! Months of letting myself operate in an impaired state for stupid reasons—denial, busy-ness, and putting everything else in front of myself.
Being able to take a deep breath makes me a better person, more capable of helping others and getting things done. So does getting a full night's sleep, eating clean, cutting caffeine, and getting exercise. So does paying attention to my moods, and how my body feels, and doing something about it instead of ignoring it by occupying myself with whatever thing outside of myself that's keeping me busy-busy.
On a daily basis, I'm not succeeding at all of this, or even most of it. But from here on in, I'm going to try to remember how profound it felt to finally put on my oxygen mask. And every once in awhile, I'm going to ask myself the following questions. Join me, won't you?
What's going on with you that you've been putting off, ignoring, and that needs your attention? What deep breath are you denying yourself for dumb reasons? What would a couple of hours of investing in your own self-care yield? Do it now.
Do You Want to Be Pretty?
My daughter will turn 3 years old soon, and she has lots of opinions. Opinions about what book we should read next, or whether she should eat another green bean, or whether it's time for tickles or snuggles or chasing her across the room or "by myself!" time. Certain things, though, she could care less about--like what clothes we put on her in the morning. Getting dressed is just a hurdle to get through so she can get back to play time.
I worry, though. It feels like a matter of time. Several of my most feminist friends are as dedicated to helping their girls to choose their own gender expression as we are, and they've succumbed to it. The tiaras, the tutus, the sparkles, the elaborate headbands and bows.
There's nothing wrong with femininity. There's something wrong with the fact that it's the default choice for little girls. And that if you're a little girl amongst other little girls in American culture, you're weird if you're not into it.
We haven't been able to stop it. The relentless onslaught of princess culture finds its way to our girl through the most well-meaning channels. Her grandmother, her babysitter, her daycare teachers. Without thinking they call her "princess", gift her baby dolls and plastic makeup kits, ask her if she wants to try on their earrings, suggest that she play dress-up, pick out the pink toys for playtime.
We counter-program like it's our job. I believe that it is. We put her in clothes that are not from the girls section . We secretly donate the plastic lipsticks and hand-me-down frills. We encourage her when she pulls barrettes out of her hair and declares she doesn't like them. We buy toys that come in primary colors, with little boys smiling on the box. We stopped watching Thomas the Tank Engine because 90% of the characters are male. We encourage her love of Doc McStuffins, one of the only kid shows we've found that features a smart, capable girl who is the main character and protagonist. 
Still, it feels like it's coming. Our housemate, a bright, energetic 4-year-old girl, loves to play dress-up with her collection of princess dresses. She pulls our girl into it whenever they're in her room. I hold my breath, and hold my tongue. If my daughter wants to wear a princess dress, she shall wear a princess dress--as long as she's not pressured into it. As long as she knows it's not her job. 
During one of these sessions, my daughter was more interested in the dragon costume hiding at the bottom of the dress drawer than the dresses themselves.
"Do you want to be pretty?" the 4-year-old asked.
"Nope," my daughter said, without hesitation.
Nope. I think about that nope. I celebrate that nope. I will recall that nope when it turns into a yep, or a maybe, or a question about what pretty is.
I don't love the premise of the question, a question boys don't have to answer. But in the face of our culture's defaults, it is a question I hope my daughter has strong, varying opinions about.
Do you want to be pretty?
Nope, I don't feel like it.
Only if I get to decide what pretty is.
Yes, that sounds like fun.
Yes, and I want to be a leader, or a builder, or an athlete, or a scientist, or a teacher, or a doctor, too.
 The boys' clothes section is often just as bad as the girls. To avoid buying shirts that say things like "Daddy's little football star", we try to buy gender-neutral stuff, which is harder to find and often more expensive.
 Even with a stay-at-home Dad character, a Mom who is a physician, and Geena Davis of Thelma and Louise fame voicing a toy princess who tells a toy knight that she can do everything he can do, Doc McStuffins' stethoscope is still pink.
 Thanks to Caitlyn Siehl for her poem, It's Not Your Job.
Just five bucks a month
I was a web developer for nearly 20 years before I ever built web pages that accept payments from customers. I'm not sure if that's a comment on my career in particular or the industry as a whole. But the day finally arrived in 2013, when we at ThinkUp decided to try something uncommon: build a web business supported by customer subscriptions instead of advertising.
Since then, despite relying on third parties to handle all the complexities of credit card transactions, we've developed and deployed seven billing-related projects. SEVEN BILLING PROJECTS. It's April of 2015 now. That means our tiny team launched a new billing-related project every two to three months. In short, during the entire existence of our business, we've been constantly occupied by designing and building a system tangential to our actual product (albeit core to our business).
In order to assure myself that I'm not crazy for being tired of billing-related code, I'm documenting our journey so far here. Maybe it will help someone out there make decisions about their new subscription-based web product.
Project 1, October 2013: DIY Crowdfunding
Before we launched ThinkUp, we wanted buy-in from the community. As an open source project built for the community by the community, it made sense. Given the rise of Kickstarter into the mainstream and the audience that my co-founder and I had through our writing and podcasting, we knew we could pull off a successful crowdfunding campaign. We also knew that ThinkUp would be a subscription service, and we wanted to start capturing recurring payments from day one. At the time, Kickstarter and other crowdfunding platforms didn't support recurring payments. (Patreon hadn't launched yet; but it wouldn't have made sense for us anyway. ThinkUp is squarely a subscription service versus arts patronage.)
We knew we'd have to write a subscription billing system anyway, so why not start with the crowdfunding campaign? Following in Kickstarter's footsteps, we decided to use Amazon Payments over more developer-friendly options like Stripe to collect payments. Anil and I both loathe entering credit cards into web pages. Our target customers already have Amazon accounts. We felt that the user flow for backing Kickstarter projects, which ThinkUp would emulate, was so smooth and easy it would enable even impulse backers to pledge a subscription on their tiny mobile device screen.
Because it was a crowdfunding campaign modeled closely after Kickstarter's flow, there was one particular requirement that had serious repercussions for us down the road. During the campaign we'd collect credit card authorizations—agreements from our backers to let us charge them when the product was ready. We promised we wouldn't charge anyone until January, when ThinkUp was available for them to use.
This had two big implications on the backend: first, we'd have to use Amazon Flexible Payments Service, Amazon's more advanced, customizable payments API which allowed apps to collect authorizations first and not charge till some much later date. It also meant we could put off writing any software that performed actual charges until later.
So while over 1,000 backers gave us permission to charge their Amazon account a lot of money in aggregate, our system wasn't ready to do that—until a special day in January, the 17th, when it was time to run the charges. That day we collected a lot of money from our backers—and a hell of a lot of payment failures.
Remember the Target hack? Forty million credit cards were compromised, and a great deal of them were owned by people who backed ThinkUp's crowdfunding campaign. In the time between ThinkUp collecting the authorization to charge their card, and the charge itself, almost a third of our backers had changed their credit card thanks to Target. And thanks to things like Gmail's Priority Inbox (a majority of our subscribers use Gmail), spam filters, and just busy people who don't get through all their email every day (like me), a majority of those failed payments went unfixed because backers simply never saw the multiple emails from us and Amazon alerting them to the failed payment.
While I am eternally grateful to every single human who backed our campaign, failed payment or not, it was a bummer.
Project 2, March 2014: Annual subscriptions
ThinkUp launched on time to its crowdfunding backers in January, but it was available to only them. We weren't yet open to the public. Mostly this was because ThinkUp the product had a lot of bugs to work out, but we also didn't have the billing system in place to collect an authorization and charge it immediately. Each day, by hand, I'd run a script that collected stray charges left over from the crowdfunding campaign, and we scrambled to put out instructions on how to update your payment method and fix failures.
In March we finally opened up to the public, and began accepting annual subscriptions on the spot. We were still using Amazon's Flexible Payments Service, with the key difference that the charge happened immediately after the authorization. The immediacy of the charge cut down on payment failures a whole lot.
Project 3, July 2014: Free trial
Once ThinkUp was open to the public, the software was a reality, and we'd exhausted the goodwill of crowdfunders who were inspired by an idea presented in a video, it was time to get real. ThinkUp's annual subscription price was pretty high ($60/year for members, $120/year for Pro plans). Without a way to try the app out first, our subscriptions slowed to a trickle, and cancellations after a week or two of using the service spiked. We had to offer a free trial.
Our one big requirement for the free trial was that we could say: "Credit card not required." We hate free trials that collect your payment information upfront, and then when you forget to cancel, charge you automatically. So, on the backend, this project had less to do with billing, and more to do with building in a trial state where the user hadn't paid yet but was still getting access to the full app. We also needed reminder emails letting trialers know they had X number of days left to pay in order to keep their account active.
Once we launched free trials, it was a thrill to see so many people try out the app. This is when, as a business, we started concentrating on converting users—not just from landing page to signup, but from trial to paying subscriber.
Project 4, August 2014: Monthly subscriptions
With free 14-day trials in full swing, we poured a great deal of effort into making the first 14 days of app usage the best they could possibly be, in order to convert more subscribers. But the annual subscription fee was still pretty high, and we fiercely debated internally if we could market a $60/year product as $5/month. Not until our customers could actually PAY monthly, I argued.
It wasn't until we had to offer monthly subscriptions that all the highly-customizable-but you-gotta-do-it-yourself of Flexible Payments Service (FPS) became a liability. I didn't want to create cron jobs that ran daily charging people on a monthly basis. That figured out if someone paid on January 30th that it should recharge them on February 28th the next month. That had to deal with timezone stupidity. That meant we lost revenue if our servers had a problem. I wanted someone else to handle all that for us.
We were still convinced that Amazon Payments was the best user interface. So, since we wanted to stick with Amazon Payments, we switched to Amazon Simple Pay, a wrapper for FPS that handles recurring charges for you. Subscribing to a service via Simple Pay was still a one-click affair, and Amazon did all the recurring charges for you. Great!
Around this time, our Amazon Payments account manager got in touch, pitching Amazon's new payments product, Login and Pay with Amazon (LPA). He wanted to set up a call about ThinkUp migrating to LPA. I looked at LPA's documentation, and it appeared to be built for web sites selling physical products, geared towards businesses who needed a full shopping cart experience and had to collect shipping addresses. It didn't offer subscription management. That wasn't for us.
In a decision I regret to this day, we decided to go with the older, established Amazon Simple Pay instead of the new Login and Pay. Even though LPA didn't offer features we needed, I ignored very obvious signs that Simple Pay was no longer on Amazon's roadmap. The code libraries hadn't been updated in years. For a business as small as ours, our Amazon account manager pursued us with a lot of persistence to consider switching over.
Project 5, November 2014: Coupon codes
It's not easy getting consumers to pay for recurring subscriptions on the web. In an effort to boost our sales during the holiday season and give users the opportunity to give ThinkUp as a gift, we launched The Good Web Bundle. A partnership with four other subscription sites that we love, a user could purchase the "bundle" for a discounted price. When they did, they received a coupon code they could redeem at ThinkUp and at the four other sites for one year of use.
The big difference between this project and the earlier work we'd done was this was the first one-time purchase a user could make. We used Amazon FPS to give users a link to make that one-time purchase, then emailed them a unique coupon code. Just like the other four sites, we built in the ability to redeem that code for a year of ThinkUp in our membership system. Similar to free trials, this was a matter of creating a non-recurring subscription state in our system that ended on a date exactly a year away from redemption.
It was around the bundle's launch that we heard a troubling rumor from a reliable source. Amazon was going to discontinue Flexible Payment Service (including Simple Pay), and go exclusively with Login and Pay. Kickstarter was switching to Stripe.
THAT put a damper on the holidays.
Project 6, January 2015: First annual renewals
In January, our first annual renewals were up from the crowdfunding campaign. Since those came in via FPS and not Simple Pay, we'd have to recharge them manually. We were hyper-aware that most crowdfunding campaigns do NOT charge you again a year later, so we spent a good amount of time writing and designing email notifications for crowdfunders informing them that their annual renewal was coming up. We sent one 2 weeks before the member's renewal was due, and one week before. I wrote code that gave users the ability to close their ThinkUp accounts and get a pro-rated refund via FPS right inside ThinkUp. (Prior to that, they had to email us, which sucked.)
Then, each day we ran the annual renewal charge job by hand as members came up on their renewal date. There were a ton of payment failures again, due to expired or changed credit cards, and a good number of users closed their accounts because they hadn't used ThinkUp as much as they thought they would. That is understandable, if hard to watch. I was glad to finally give our members a guilt-free escape hatch if they wanted out.
Project 7, March 2015: End-of-life
In January, Amazon made the announcement official: Amazon Flexible Payments Service (FPS) would be discontinued effective June 1, 2015. Worse! Existing subscriptions would NOT get automatically migrated over to Login and Pay. Our customers would have to come in and pay again.
In short, the payments API our entire business was based on, and the sole source of our revenue, was going away. I'll be honest: I spent a couple of weeks feeling crushed. We'd worked hard to acquire every single paying ThinkUp subscriber, and we know that in the transition, because of lost emails or busy lives or second thoughts, we will lose customers. Not to mention rewriting our billing interactions and backend again to work with Login and Pay.
We thought long and hard about moving to Stripe. To Amazon's credit, our account manager and a solutions architect spent a great deal of time with us, offering help, making suggestions, accepting bug reports. Login and Pay does not offer subscription management, and that was not software I wanted to write in-house. Among a handful of other products, Amazon suggested we check out Recurly, which offers recurring subscriptions via Login and Pay. Beyond offering way better customer management features than Amazon Payments itself does, Recurly offers integration with Stripe and PayPal, generates customer invoices, and made offering both a monthly and an annual subscription plan very easy.
So, last month, we removed the Amazon Simple Pay code from ThinkUp, and we're now accepting payments via Login and Pay with Amazon (by way of Recurly). The customer experience is just as simple as it always has been, with one additional choice: between a monthly or a discounted annual plan. Recurly, of course, takes a cut, but given the dev time they saved us and the features we'd never build by hand, it's worth it.
Having been through these past 20 months of billing system development, I truly appreciate the value of app stores, and how they let software developers worry about their software instead of accepting payments.
It might seem like the moral of the story here is "Don't depend on third-party billing services—especially Amazon Payments!" But I don't believe that. As a small startup you don't have a choice about depending on third-party services that could get pulled out from under you on any given day. Even all this was more efficient than building our own in-house credit card transaction service. And there's no telling how things would have played out if we had, say, gone with Stripe from the beginning. Maybe we would have skipped a lot of steps in this journey so far and had a ton more time to focus on ThinkUp the product versus handling subscriptions. Maybe we would have had a lot fewer customers who didn't want to enter their credit card into a new app they didn't trust yet. Maybe in the end the dev time we saved would equal the revenue we'd lose. (Though I'm not sure Stripe would have supported delayed charges the way Amazon FPS did at the end of 2013.)
When I started building subscription payments into ThinkUp, I had zero experience and only vaguely understood the difference between a credit card authorization and a charge. I was dumb. Today, so far, I'm really happy to pay someone (sometwo, actually, between Recurly and Amazon) to do the work of dealing with payments, invoices, recurring charges, and expired credit cards for us.
Amazon FPS and Simple Pay will stop charging our customers as of June 1. Between now and then, our EIGHTH billing project will be asking our current customers if they will re-pay for their subscription. Wish us luck.
You are so much better than exhibitionist-you
Years ago, I asked a friend of mine if he'd seen a blog post by a mutual friend.
"I don't read his blog," he told me.
I was surprised. These two had known each other for years, and hung out in person a few times a month. I inquired further.
"He's one of my oldest and best friends, but I don't like who he is on his web site. He comes off so differently than the person I know, and I don't like that version of him."
Today, replace blogging with Twitter and Facebook, and I understand this sentiment better than ever.
When you follow someone online who you adore in person, it's a gamble. In the best case, you gain a magical social sixth sense about your friend's life and work that enhances the relationship. In the worst, they turn out to be an irritating exhibitionist, religious/political/Crossfit/[insert current trend] fanatic, or strident wanna-be thought leader. And it makes you love that person less.
The "unholy mix of exhibitionism and voyeurism" that is social networking can have the opposite of the intended effect. When social tools alienate friends more than connect them, we've failed.
When we do, the responsibility is on the platform as well as the people on it. When a platform encourages thoughtlessness, reductionism, popularity contests, and feedback loops that reward viral soundbites or dumb jokes, its users will run with it.
But we don't have to. We get to decide how we show up every day online, where our words and pictures and links and commentary is permanent and beamed to dozens, hundreds, and more and more often, thousands of people—to greater effect than we may know.
It's also on you and me to demand that our platforms get better—to facilitate more thoughtful interactions, empower people to combat meanness and bullying, to help people share their real, awesome selves. One of the things I happen to think is missing from our networks is a mirror that shows you what you're doing there. I'm working on my take on that mirror right now and some days I don't like what it shows me.
The truth is, exhibitionist-me can be a real jackass sometimes. If you see her online, let me-me know and I'll work harder on keeping it real.