I've disabled all LLM-based AI Assistants/Copilots/whatever-you-call-'ems in my IDE.

Take a moment to let the shock, horror, and betrayal to pass through you (or, potentially, the giddy "OMG I'm not alone!" squeal burbling up from deep inside), because I'd like to expound for a bit about why I've done this, and I know the title is a bit of a giveaway, but no, it's not because I'm some cranky old man who can't stand that new-fangled ding-dang technology. Well, I mean I am old and cranky, but what I mean is I work at a company that heavily uses AI to augment real, serious professionals' capabilities. I'm not an anti-AI absolutist or anything.

I just think that it's a disaster waiting to happen for the software development industry, is all.

Here's my core thesis:

LLMs will never be as capable as we have been told they will be. All of ginned-up demos that we've been shown around LLM-based tools being given a three-sentence description of a feature and building it and writing the tests and reviewing itself and deploying it, all automatically? They don't work now, and they never will. LLMs can never "know" or "understand" anything. They seem to have interesting emergent properties, but every new announcement about those capabilities quickly falls to pieces in the Hacker News comments, as curious devs give it a try and find that it actually doesn't work quite that well, at least not under all circumstances, and critically, not to achieve the overblown promises we're being sold around feature-scale AI code generation. Hell, this just happened again with the release of OpenAI's o1 series of models, models that we are told "think" but in actuality do nothing of the sort. They mostly just go "hmm" and "ah!" a lot, and then over-charge you via a new secret token mechanism to return dangerously close but not-quite-right code just frequently enough to cause serious problems down the line.

It would appear that we're hitting the upper limits of practical model sizes, too. Larger models have been the source of new and interesting improvements of these models, the "secret sauce" of the AI boom, as it were. And larger models can be trained, but the cost to train them (and retrain them when necessary), plus the cost of then running them looks to be prohibitive. We can see this in the latest ChatGPT models, the 4o series, which are smaller and less expensive than the original ChatGPT4. Even o1 doesn't appear to be a significantly larger model, it's likely just a pretty solid implementation of "chain of thought" prompting with existing models. ChatGPT5 it ain't, but maybe, when and if we get ChatGPT5, it'll will be another significant jump, like 2 to 3 was, or at least 3 to 4. But the basic architecture will almost certainly still be the same, the LLM architecture. We were in an "AI winter" before someone discovered that Big LLM Make AI Go Brr, and we'll be right back in another one once we hit the practical maximum sizes of LLMs, if we haven't already.

Again, I'm not saying that LLMs are fake and that there's a man behind the curtain (except when there absolutely is, although that's not the topic of this essay), or that there's no use for LLMs. There are a variety of uses that make very reasonable sense, even in the field of coding! But using them to generate code is Not It. Absolutely no large-scale feature-generation tool has survived contact with the general public just trying to use the service as described, and I think even the small-scale code generation tools are dangerous in ways we're not really talking about yet. These are not tools that reward time invested into learning them, because they do not turn out the same quality of work. Hell, its arguable that they don't even turn out work of acceptable quality (and that is the side I would, in fact, argue). LLM-generated code of any real-world size and complexity -- you know, not just used to create toy examples to demo the product to credulous CTOs and slavering CFOs -- this code is almost invariably of just miserable quality, lacking any refinement or robustness that comes from a proper understanding of the problem area and the surrounding system, for exactly one critical reason: LLMs do not understand.

There are people who will debate me on this, and they tend to do so with arguments that point to what seem like surprising emergent properties, but these people are like audience members in a magician's act who point at the wriggling feet of the woman who was sawn in half and deny what their logical mind knows to be true -- this is all a trick. The fundamental method that is used to create an LLM -- that is, predictive text based on input weights -- this is not something that can generate an understanding, it is only something that can seem to understand, in certain limited circumstances, for a little while. Every new generation of LLM release has gone through the same cycle of marks crying "Look, finally it understands!" only for actual users to immediately run up against the limits of this supposed "understanding." Definitely, these new models are more impressive, and there are more and more cases where their careful, considered use is looking more reasonable, but none have (or ever will) spontaneously developed the ability to "understand", much like how an apple has never spontaneously developed the ability to harmonize, despite them being able to make your tastebuds sing.

But it's worse than that.

It's not just that people are putting time and effort into learning a tool that won't pay off in the manner the hype-cycle has promised, this is a tool unlike other tools that have come before and promised improved productivity, because in actuality, it makes you less effective over time. You may get better at "prompt engineering" (UGH), but you are sacrificing your knowledge and understanding of the system and tooling that you're working with, like trading a worthwhile, solid cow for magic goddamn beans, except that outside of fairy tales, beans are only ever beans.

Think about a custom furniture maker who takes down the project details, then takes that information to Ikea, asks the salesperson for something similar, bangs it together in an afternoon, and delivers that instead. Some people are going to be thrilled that they have their furniture that very same day, sure. They may not even notice that the furniture is painted particle board and not a decent slab of hardwood, because they didn't think to specify that in the details. But they for sure will notice that the third or fourth time they have to move it, that it starts coming apart and needs more and more-intense repairs to keep it in one piece. And when this furniture maker does finally get a project that specifies aged mahogany, mitred dovetail joints, and hand-carved engravings, they just do not have the skills to build it. This is the future we're headed towards.

There's two important ways to evaluate these reduced capacities: in the near term, i.e. what it means to projects we are working on currently, and in the long term, i.e. what this means to the greater industry.

The near term is bad enough. The obvious and immediate drawback is to code quality, as AI-generated slop starts sneaking into codebases. Tight timelines and aggressive deadlines (which are more and more frequent everywhere, have you noticed?) means that we've had to rely more and more on trust that our co-workers are doing the good job they say they are. I love when I get some time to do some truly focused review on submitted PRs, but all too frequently, it's hard to justify more than a merely "decent" evaluation, plus maybe a closer look at a few key areas before you have to stamp it with the ol' LGTM and get back to trying to hit the deadlines on your own tasks. (This is a problem in its own right, but again, not the subject of this essay.) This process of leaning on trust makes it incredibly easy for bad LLM code to slip in, because the number one thing that LLMs are good at is generating text that looks like it belongs. Again, they don't understand, so they can't be relied on to write correct code, but they can be relied on to write code that looks correct, so these time-restricted, trust-reliant, scan-based reviews are tremendously vulnerable. And even when you do have time to do a more-thorough review, you're not perfect and will never be. In security, this is why you rely on "defence in depth," which in coding really ought to start with "the coder submitting the PR believes they thoroughly understand and stand behind the code they are submitting!"

I'm struggling at this point not to write "but it's worse than that" over and over and over again, but, well, it's worse than that. Not only is this extra source of bad code increasingly finding its way into our systems, but the developers who should be writing and reviewing and revising this code are just not learning the skills required to do so. Moreover, they're not learning about the intricacies and pain points of the system. They just won't know about the parts of the system that are hard to reason about, that are more likely to introduce bugs when worked on, that can be expanded on safely and quickly or that require a refactor before any serious work can be done with it -- they just won't get the experience to develop a low-level understanding of the system that helps them reliably and quickly continue to build with it. They're farming that work out to co-workers who do have that understanding, who leave ever-more-frustrated comments on reviews asking them to please consider the broader context of the work they're doing, and then they pipe that into their prompt, asking their LLM to "Please revise this PR taking Maria's comments into account then commit then push." And poor Maria has to repeat this cycle of indirectly prompting an LLM until between the three of them, they get lucky and the problem is finally solved, all while trying to get her own work done as well.

Beyond just the systems being worked on at any one company, though, there's the effects on the wider industry - junior developers who become dependant on LLMs can likely seem like incredibly fast learners and can likely present as intermediate developers instead. This doesn't truly reflect their skills - they may seem faster than junior/intermediates who are learning for and by themselves, but beyond that, I highly doubt an LLM-dependant developer can even exist at the senior level, and especially not any higher.

Note: I'm not saying you can't use LLMs and be considered a senior developer, I'm talking about dependance. i.e. Do you yourself know how to program, do you have an intuitive grasp of how various common algorithms and data structures work, can you personally make logical leaps when debugging thorny issues? Or are you relying solely on LLMs for this competency? If the latter, I would absolutely not call you a senior developer, and I wouldn't let you within rock-throwin' distance of a keyboard that could even conceivably commit to any repositories I cared about.

Obviously there's a limit to how much of this bathwater I'm going to throw out - there's a baby in there somewhere! For instance, given how terrible Google's search has become recently, asking an LLM to provide you with a decent introduction to a hard-to-research topic is not a bad place to start gaining familiarity! (Provided, of course, you fact-check what it tells you.) As developers, we use all kinds of tools and technology to make our life easier and to make writing code less onerous. Intellisense is a godsend for people like myself with memory issues (I can remember the "vibe" of a function, but I hate wasting time remembering if a function is named search_user_text() or search_text_user(), or what the parameter order is, etc.), and while writing MIPS can be a lot of fun, I wouldn't want to write assembly code for my day job -- I'm thankful every day for high-level languages.

But the difference is that those tools tend to work to enhance our understanding of the problem domain, while encapsulating things that are outside of that domain. You don't need to know Linux C source code like the back of your hand to get your job done (unless your job is working on the Linux kernel, I suppose), but tools that make it easier to represent and understand your business domain are critical to a modern developer. LLMs are the opposite of that - they tend to generate code that looks like their sample data, not necessarily your codebase, and they remove the need for you to understand your tools or domain at all! ...at least for a surface-level approximation of work.

That famous Steve Jobs saying, "A players hire A players, B players hire C players?" Well, it may have been heartless, but there's a logic to it. That said, I think it needs updating for the modern era: "A players hire A players, B players hire C players who hire AI chatbots and pretty soon nobody knows how the fuck anything works anymore."

Photo by Adam Jaime on Unsplash

I was scrolling through my Mastodon feed and saw a catchy and punchy post pop up:

Fuck yeah, right? I'm really sick of watching homeless encampments get rumbled, the people living in those camps losing their shelters, their belongings, their tenuous grip on survival, and told to move on without being given any clue where to move on to. So they move on to the next place they can set up a camp for a while, and the whole cycle repeats itself.

And these camps aren't broken up as a matter of policy, they're broken up because locals complain. "Property values" decrease, people get worried for their safety, for the safety of their stuff, and instead of trying anything to help, tens (in some cases hundreds) of thousands of dollars are spent on police operations to clear them out.

But posters like this will not fix the problem. In fact, they're likely to make it worse.

I get it. I feel the frustration too. I wish I could shame people into giving a shit, or dunk on them so hard that they become a better person, but in practice, that's not how it works out. Instead, people tend to get angry, and worse, they tend to get entrenched. Then, instead of a chance at persuading them, you've got a fight on your hands, against someone who is more dedicated to their cause.

This poster, while well-intentioned, is actually very likely accomplishing the opposite of what it's setting out to do. Here, let me give you an example. Let me rewrite that previous paragraph in the tone of the poster:

Posters like this are fucking garbage. They don't make their intended audience change their minds, they just make them angry and less likely to help. Sure they make you feel good, but you're already on your way back from your bougie-ass hipster cafe with a overpriced coffee – you're taken care of! Shouldn't the point be to help the fucking homeless, not yourself?

What the fuck is wrong with you?

See, doesn't that suck to read, when you're the target? I don't want to agree with that guy, regardless of the merits of his points, I want to fight him!

I like to joke that my alignment has progressed over the years from "Lawful Good" to "Awful Good," because I really love hot takes like the one on the poster, but I've also grown to realize that despite how good it feels to indulge in righteous anger, it doesn't actually do any good for your cause.

What works better, and what is much, much harder, is to try to step back, find some common ground, and write from that shared perspective. Nobody's ever going to think "You know what, maybe I am an asshole! I guess I'll change! Thank you random poster!" But you might get a few to think "You know what, maybe I, a caring and decent human being, could show that decency in a few ways I hadn't yet considered! Thank you, random poster!"

I'll leave a rewrite of the poster as an exercise for the reader, but again consider the target audience. How do they see themselves? How can you rewrite the issue of tents as something they could align with? What are they afraid of or mad about? How can you show them addressing that fear or anger as a virtue?

Maybe just don't call them an asshole, though.

Photo by Sarah Kilian on Unsplash

Look, I get the noble intentions that originally spawned the movement, but y'all, capitalism is winning, and Open Source isn't changing that fact by an appreciable margin. What it is doing, however, is convincing a whole lot of talented people to donate critical hours of their life to working on tools and libraries that profitable corporations are making bank off of.

There are two miserable fates that await an Open Source developer at either end of the spectrum, one far worse than the other:

1. Nobody ever uses your code. This is kinda depressing, but you move on with life.
2. Everybody uses your code. This is amazing! Until it's not. Until people start finding bugs and writing issues and requesting features and submitting PRs and demanding to know why you haven't released in six months and talking about how this "dead repo" is now a security risk and how the developer is a deadbeat and should be ashamed, and nobody should use this library for a professional product. Congratulations, you now have A Responsibility.

This sucks. You're just trying to write and share some useful code, and if that code becomes too useful, you have somehow fucked up because you now have a second job. A second job that doesn't pay, but allows other people to make money from your labour, I should add.

Donations and sponsorships are an option, but they're not a great option. You have to rely on people to donate out of the goodness of their hearts or at least the viability of the marketing message it sends for them to be seen donating to prolific Open Source authors. And good luck if you're not prolific. If you're just quietly toiling away on a package that sees a few thousand downloads a week, you're almost definitely moving the needle for someone who's making money off your work, but you're unlikely to be visible enough for it to be "sexy enough" to be seen sponsoring you.

Open core is an option, but only for certain types of Open Source. A great many libraries are basically just the core, and don't really have any sort of "high-end business features" that can be spun off into a paid product that would interest businesses. Also, you are basically now in the business of selling a normal software product with a free loss-leader, which may not really be what attracted you to Open Source in the first place.

Charging a subscription for managed deployments is also an option, but also, again, only for certain types of Open Source. If you write a popular library, there's not much to host. You have to have a full Open Source product for this to be even something you can consider, and then there's nothing stopping a huge cloud company from offering their own integrated version of your service. And for most people it just doesn't make sense to spin up your flavour of BloopusServer when they can spin one up as an AWS component in their CloudFormation stack.

I don't know what the answer is, I just know that I've stopped feeling good about people sinking so much of their time, energy, and good vibes into this work, only for their good intentions to be taken advantage of. As power and money shifts ever more away from the people who work towards the people who own things, it feels weird and wrong to see people give away the fruits of their labour for free to the people who are getting more and more of it, cheaper and cheaper, everyday.

Photo by engin akyurt on Unsplash

Like a lot of things, the phrase "do your own research" started off life with good intentions, and then got co-opted by a certain kind of person to enable behaviour antithetical to the original coiner's intent.  Nowadays, if someone says they "did their own research," you are far less likely to cock your head and listen intently than you are to wince involuntarily, and then seek to exit the conversation at speed.

Here's the thing – you are stunningly ill-equipped to do your own research. Unless you happen to already be a professional in the field you are researching, you do not have the education, you do not have the resources, and most importantly, you are not aware of the various tripmines and tar pits that exist in that field to trap the unwary, i.e. you.  Yes, occasionally an outsider will come in with a fresh pair of eyes and see that which eluded the ossified orbs of the pros, but what happens in the overwhelmingly vast majority of times is the opposite - instead they will end up showing off their whole ass because their ignorance of some foundational shit will cause them to make a rookie mistake that those with experience would not.  Then those with experience will swoop in and eviscerate the newbie and feed them to their young.  The law of the jungle is harsh but fair.

When someone presents an interesting topic or viewpoint, your next step shouldn't be to jump to doing your own research on that topic, it should instead be to check that person's work.  This is a subtle, but important distinction.  If someone tells you that they've found out that a steady diet of honeycomb wax wards away cancer, you shouldn't immediately go and search honeycomb wax cure cancer, because they got their theory from somewhere and there's almost definitely a couple hundred blogs with titles like "medical-info-trust.com" with plausible-sounding AI-generated posts about the topic already.  You could easily spend the next four full hours finding article after article linking study after study detailing the benefits of honeycomb wax – not only for cancer, but also blood pressure, hair loss, and as a natural pesticide!  Is any of it real?  Who knows?  Not you, certainly.  You likely can't read a study to save your life, or at least not properly evaluate it, not like a trained professional with years of experience.  And if you go into this research blithely, you'll likely find convincing-sounding information everywhere you look.

So should you instead become a curmudgeon, dismissing all interesting new factoids as flights of fancy and humbuggery?  Well, it's certainly an option, and frankly one that grows more appealing every year, if I'm being honest.  But more useful is instead to instead look for dissenting opinions.  Instead, search for honeycomb wax cancer hoax or use Snopes to see if anyone's already disproven it.  And then look for arguments against the dissent!  Be honest with yourself – if you're not capable of reasonably evaluating the arguments for something, can you expect to be able to reasonably evaluate the arguments against?  Try to find people arguing specifically against the dissenting opinions you've read, not just new interpretations of the original media.  Look up unfamiliar terms or practices they mention.  Try to become familiar with the basis of why they're dissenting, which is usually a lot more accessible than the facts they're dissenting with.  (A highly-useful example is knowledge of correlation vs causation, which is bound to trip you up everywhere if you don't know about it, but can improve your ability to evaluate many things if you do.)

Try to spend an amount of time on this process commensurate with how important this topic is to you, or is likely to become.  Are you evaluating a major dietary change or about to adopt a whole new identity based on a radical new "truth" you just learned?  Maybe first make good and sure that you know and understand the arguments against your potential new truth, and that those arguments don't dissuade you.

Ultimately, you're not just learning more about the topic in question, you're learning how to do the research.  You're learning about the tripmines and tarpits that others have stumbled into.  You are learning how to be objective and how to recognize traps that could compromise that objectivity.  With time and practice, you'll find it easier and easier to see through bad-faith arguments with ill-supported facts, and the arguments you do agree with will be more well-supported and far less likely to cause you or others grievous personal harm. Scammers and hucksters will find no purchase in you, and fake online "medical journals" will receive no more of your advertising dollars.  (That said, a good adblocker will help there too.)

Doing your own research may feel like an exciting game at times, but checking people's work is where the real value is.  Though life may be a little less exciting with fewer wild and crazy discoveries finding purchase in your mind, it will also be less disappointing and/or terrifying if and when you are eventually proven wrong.

On October 27, 2022, Elon Musk completed his purchase of Twitter.  One week later, on November 4, 2022, he laid off approximately 50% of employees, killing the company.  You can still log into twitter.com, your apps still work, your integrations still work, but make no mistake: this company is dead.  It is a shambling undead corpse, with its critical central nervous systems shattered, the limbs still animating on instinct and half-firing neurons.

Everything since then, the price hike of Twitter Blue to $20/month, the discount to $8/month before it even launched, the fiasco of granting blue checkmarks to every Twitter Blue subscriber, the rampant impersonation, the attempt to fix it by changing the rules around impersonation and demanding a decimated staff keep the world in check, the introduction, then removal, then re-introduction, then re-removal, then re-re-introduction maybe of the grey "official" checkmark, the confusing and sometimes terrifying amount of new directions and product decisions Musk has been hurling around in a frenzy, his brazen dismissal of the FTC's dire warnings, his blasé attitude towards developers over the news that they might personally be held responsible by the FTC for his decisions that they implement, all of that?  Harmless, ultimately.

You cannot harm that which is already dead.

And Twitter died on November 4, 2022.

If you've never worked at a large technology company that grew large through a period of rapid expansion, you probably over-estimate how, well, okay things are, on a day to day basis.  You figure, they're this big, things must be okay, like in general, right?  Well, things are not okay at a quick-expanding large technology company, and things are not okay at Twitter.  The initial prototype for something like Twitter is usually something entirely unrelated, and from this point the team rapidly pivots between (sometimes) related product ideas until they hit on the thing that actually takes off.  From there, it's a mad scramble to just keep the thing held together while far more people start using your product than you ever expected or planned for.  The mantra at this point is something like "just keep it together any way you can, we'll deal with any technical debt you incur later, when we have time."

Reader, there is never time.

So at large company like Twitter, the technology bears these battle-scars, these overgrown jungles, these spots in the code clearly labelled "Here There Be Dragons" where wise developers fear to tread (and where unwise developers are eaten), and the only thing keeping the whole damn thing running despite all of this... are the people.  There are landmines and tripwires and countdown bombs all over that tech stack, and Elon Musk permanently sent home 50% of the people who know where any of it is or how to deal with it.

Except it's not even quite that not-okay, it's worse.  Obviously, the cuts weren't spread evenly through the company.  Many of the 50% who were fired weren't even engineers.  They came from "unimportant" teams like Trust & Safety, Accessibility, Communications, you know, silly things like that.  But even among the remainder of those fired, engineering was hit hard.  A lot of teams that support critical parts of the infrastructure are down to a skeleton crew.  Even if everyone who's left knows how to run those systems perfectly (and they don't, we've already heard stories about people unable to quickly make changes or fixes to systems because there's nobody left who knows how they work), they're going to be over-worked and burnt out and either leave or become so completely ineffective it won't matter that they're still around.

Now, it may be something else that finally stops the corpse from moving. Honestly, my money's on the fact that the advertisers are so fearful of Twitter advertising harming their brand due to rampant impersonation and a lack of assurances that Twitter will be effectively moderated that they go away and never come back.  But for one reason or another, there will finally be a point where everyone involved realizes that there's no point in keeping it running.  Either the technological burden of keeping it running will be too great for the remaining engineering staff, or the money available to pay to keep it running will dry up.  And Twitter will go away.

Even from this point, it may die a long death.  Finding a buyer for an obvious lemon like this may take a while, and to try to keep it as appealing as possible to potential buyers, they may keep it online as best they can.  But any buyer who buys this turkey won't be buying it to keep running Twitter, they'll be buying it for scrap.

Twitter still has the problem that they lost 50% of their staff, and no longer have the institutional knowledge to keep it running correctly.  This is not a problem that goes away with a sale.  To fix this problem, you need to spend more money and hire more engineers (since many of the ones laid off will have found other work and will be understandably reticent about coming back) who will have to learn these systems effectively from scratch.  That will be expensive, and Twitter is already too expensive to run with its already-ineffective skeleton crew.

There won't be much resale value to the tech -- Twitter is a very purpose-built system, designed to run a world-class social networking system, and beyond that purpose, the tech involved won't likely have much other use.  I sincerely doubt anyone will buy Twitter as an aqui-hire, they're way too big for that to make sense.  So what one thing will be left to spend any money on at all?  Simple.

Your data.

Twitter has a treasure trove of data about you -- more than just your tweets and social graph, too, even though that in and of itself is enough to make certain ethically-challenged billionaires (but I repeat myself) salivate.  While Twitter is still around for you to make these choices, follow the advice of this tweet, and go disable everything under "Data sharing and personalization" in your settings.

Also, while you're thinking about the future, start thinking about what you're going to do after Twitter.  You might want to follow the herd over to Mastodon; they seem pretty popular these days.  Or maybe you missed the idealism (and design) of the web in the 90's – you might want to try out cohost!  Or maybe both?  Or maybe neither.

For me, I'm going to try to claw back a bit of my online identity into things I control.  Sure, I'll give Mastodon and cohost a try, but I'm also going to be writing more on my blog, and putting more time into personal projects of mine, like revamping my homepage/portfolio.  I'll still talk with people I know in groups on Discord and Slack, too.  Honestly, I wonder if going back to smaller, more-targeted, niche communities that don't and can't include the whole world would be just, kinda, healthier overall.

I guess we'll find out.

Sometimes I worry about becoming rich.

Not seriously, obviously.  You don't just "become rich" on accident, so as long as I don't, say, start buying lottery tickets or writing Young Adult novels that capture the zeitgeist of an upcoming cultural wave, I should be pretty safe.

But I do get that startup itch from time to time (most recently Nodewood), and with enough work and time and luck, I could potentially parlay that into some serious money.  Maybe not Rockefeller serious, but serious enough to change my economic status permanently.

And that's when I start worrying.  There seems to be a pretty clear path of how a lot of people's ethics evolve along the path from rags to riches.  Some of the nicest people I've ever met were among the poorest, but when you hear about some billionaire doing something good, it is usually quickly drowned out by a chorus of "but check out all the exploitation necessary for them to earn those billions in the first place."  Which, you know, fair cop.

You could say that it takes an asshole to amass a billion dollars in the first place, and it's not that money changes them, but that the money amplifies the already-nasty tendencies. To a certain degree, I'm sure that's true.  But I've also watched it play out on a smaller scale with friends, peers, and public individuals in the startup space, and you can see priorities start to shift once they hit a really transformative MRR.

There's a saying that makes less sense these days, supposedly attributed to Winston Churchill, but actually much older: "Anyone who is not a liberal at 20 years of age has no heart, while anyone who is still a liberal at 40 has no head."  This, I believe, made a lot more sense in an age where you amassed wealth fairly reliably as you aged.  But the boomers were the last generation that were able to observe this trend.  Gen X, Millenials, Zoomers, we've all been watching that economic inequality index just rise and rise for a while now.

The further up you are on that index, it seems like the worse are the stories that seem to come out about you.  Trump, Epstein, Musk, Thiel - there's skeletons in all those closets, and for many of them, the closet door is wide open and we've been staring at those skeletons for a long while.  Pick any large corporation, and you'll likely find them funding the most vile political campaigns out there - not because their corporation especially stands for that politician or their ideals, but because there's a material advantage to having supported the winning candidate, and ideals are worth less (to them) than money.

Even the act of being a billionaire is just an incredibly evil act.  Amassing that wealth in the first place is morally wrong.  I don't think anyone needs to be shamed just for making or saving money, or providing for their family, or setting themselves up for a safe & comfortable retirement, or even just enjoying some luxuries.  Not all of life should be about barely scraping by, or what's the point of striving, of living?  But at a certain point, you have to look at your wealth and realize that it is excess.  And that excess could be doing good in the world.  It could be literally saving lives, by investing in food security programs, housing programs, treatment programs, etc.  Choosing instead to hoard that excess wealth means you are effectively depriving people of food, of shelter, of health, of life.

I play the lottery from time to time, largely as an excuse to daydream about how I would spend the money.  In my daydreams, I travel the world, I relax on white-sand beaches, I buy my friends and family houses, I throw parties, all kinds of wild luxury.  But my actual plan, were I to actually get the winning numbers, is to donate the vast majority of the money immediately to registered charities and social programs.  The jury's out as to whether winning the lottery makes you happier or not, but I couldn't in good conscience hold on to all that excess wealth knowing people were starving, homeless, and sick.

Or could I? A lottery's a lot easier to theorize about, because it's clear and obvious. I wouldn't have had the money for a long time before the choice to give it away came up, so it wouldn't have had a lot of time to work its way against me.  I like to think I have a fair shot of making those donations.

But a startup is different - it takes work and time and luck to have a business pay off.  Your wealth tends to build slowly.  Overnight successes are typically ten years in the making.  Along the way, that ever-building wealth changes your concerns.  At what point does that change become catastrophic to your morals?  How can you even tell?

There's no "One Right Way" to evaluate a business idea; it's a very personal process. Everyone has different requirements and priorities that they have to balance, and what might be an amazing idea for one person sounds like a terrible idea for another.

I co-host a podcast called The Modest Product Podcast where Steven Abadie and I talk about our experiences trying to build, launch, and run modest products.  I've spent a couple years working on Nodewood, a JavaScript SaaS starter kit and while it's in a pretty good place, I'm looking for my next project - one I can use Nodewood to build, and in doing so, improve it.  I don't want it to just be a "toy" project either, I want it to be legitimate business idea that fits my ideals and could really help people.  Why waste my time and others?

So I'm evaluating each idea I'm considering carefully, and I wanted to share a little bit about exactly how I'm evaluating them.  This might be helpful for other people looking for modest or "bootstrappy" business ideas, but it will also help me formalize some of my thoughts on the subject.

Obviously, some of these considerations are more important than the others, but this isn't a ranked list or anything where you can do math to come up with the quantifiably-best idea. It's more of a series of lenses I use when evaluating an idea, to make sure I'm taking as many important weaknesses and strengths into account before I'm more seriously invested.

Oh, and credit where credit is due!  A lot of these ideas come from a conversation hosted by Justin Jackson.  He started collecting ideas in a Google Doc, and I decided I wanted to expand on it for my own benefit.  Then I figured I may as well share what I'd come up with, in the same spirit the original list was shared.

Is this an exciting product?

You may have heard that there's two kinds of products: "vitamins" and "painkillers".  It's a very simple idea and doesn't fully or cleanly divide all products, but it's a useful way of understanding how people will potentially view your product.

"Vitamins" are nice-to-have products that make your life easier or better in some way, that you know you probably should use, but are easy to put off until later when you're "ready."

"Painkillers" solve a clear and present need that is not yet met.  Painkillers are exciting, because they enable you to significantly improve your business or yourself in a way you may not have thought previously possible.

This isn't a clear dichotomy, because products that used to be considered vitamins can transform into painkillers as technology and culture advances (sending email invoices for physical services, for example), and vitamins in one niche may be critically needed painkillers in another.  But when you consider the product and what it enables for your target market, you should be able to understand at least, is it exciting?

Exciting products are easier to market, more prone to being spread by word-of-mouth, and generally require a lot less customer education, which limits the amount of "extra work" you have to do with a constrained amount of free time.

Does this solve a significant enough problem that people will pay for it?

Constraining your solution to a too-small problem space will definitely make it easier to build, but it can leave you with a product that's not really worth buying. Collecting and storing people's receipts online (for an example that may or may not come from my own experience) may be useful as a backup for people, but without some sort of time-saving scanning/OCR and tax preparation calculations, it doesn't really solve a significant enough problem that the alternative (store them all in a shoebox and deal with it at tax time) doesn't solve just as well.

Will customers regularly use and see value from this product?

A product that people regularly interact with is a lot easier of a sell than one you use infrequently, even if the value obtained is the same.  If a user logs in every day or week, then when the monthly invoice comes up, they remember you and the value you delivery.  If they log in once a month or less, there's a better chance that they'll forget or be ambivalent to the value you deliver, and cancel.

Does this product provide value to companies at broad stages of their life cycle?

One of the problems with Nodewood was that it was only really valuable to companies that hadn't started working on their product.  Since it's a starter kit, if you've already started, you don't really care about it.  This means that the marketing for Nodewood has to start very early, building up brand awareness with people who may eventually start a SaaS business, and will hopefully still remember you fondly at that point.

It's much easier to market a product that applies to a company at broader stages of their growth. Not to mention, they're much more likely to have money to spend in later life cycle stages.

Does this product align with your values?

I mean, pretty obvious here.  If you can't stand Bitcoin, don't start a Bitcoin app.

That said, you probably want to take a minute to think about second-order effects here.  The original inventor of NFTs had lofty goals, but didn't think about the scam whirlwind they'd eventually unleash.

Do you like your potential customers?

If you've never gotten along with teachers, for example, it might make it difficult to properly empathize with educators as potential customers.  This can make it harder to identify the real issues they're facing, and, at best, delay finding product/market fit.  It can also crater your motivation, since you'll be working with these customers regularly, and if you don't value those interactions, it can wear on you.

Will you be able to stay motivated to work on this product?

This is as much a personal question as a product question, but products naturally have different "cool curves", where motivation to keep going ebbs and flows.  If your product requires a lot of motivation up-front to power through some boring bedrock, and you're currently feeling burnt-out, you may never get off the ground.

Conversely, if your product is fun to build but challenging to you to sell and maintain, you're going to have a great time writing code, but running the whole business may end up being a chore.

This is one of many areas where considering a co-founder could help shore up any potential weaknesses.  In addition to them being able to take on tasks that would wear you out, you can share tasks that neither of you want to do, as well.  That way there's half as many of them, and you have a shoulder to cry on afterwards.

Can you build this product in a reasonable amount of time?

If it's going to take you two years to just build the MVP, you're going to want to consider the problems that come with that.  Motivation, as we just discussed, will be hard to keep up for a long period of time.  The market opportunity you identified may dry up or be filled by a competitor.  There is likely significant technical risk in such a long project, and it may take longer than the projected two years.  Additionally, iterating rapidly on such a complex prototype is likely to be difficult as well, which means you could have a harder time achieving product-market fit.

On the other hand, if it only takes you a couple weeks to build out the majority of your product, you're going to be vulnerable to fast-following competitors.  Established players in the market could duplicate your offering with their superior resources, or, even if the niche you've identified is too small for them to care, other bootstrappers could likely replicate your work just as quickly as you did.  Quicker, too, since they'll have your work as a blueprint.

Every product has a moat you build as you build it.  Too much moat and you may never get across yourself.  Too little, and the barbarian hordes will just flow right across.

What is your moat?

To expand that last thought a bit, it's helpful to ask yourself: What will the moat for this product be?  What hard work or specialized knowledge or access will you need to develop, and are you okay with that?

And if you can't identify a moat, again, beware of fast-followers.

Is this product easy to distribute?

One of the early ways that Google tried to monetize search was by selling Google Search Appliances - you'd purchase a physical Google rack-mounted server, connect it inside your data center, and let it index internal documents for you.  A really neat capability for businesses to be able to have at the time!

They obviously no longer sell this hardware, and one large reason is that it was a royal pain in the butt to distribute and maintain.  Since it required actual physical delivery and setup, there were all kinds of technical and legal hurdles to move past before a sale could even be agreed on, and then scaling that business became a chore.

You likely aren't looking at building physical computing appliances for people to install in their data centers, but the modern equivalent is on-premises software.  Far less frustrating to install, but still very frustrating, when compared to a simple SaaS.

And even if distribution is fairly simple, if your product requires a fair amount of work for your customer to set up on their end before they see even a shred of value (snippet installations, workflow building, time to evaluate data), this will also slow down your sales cyle and add to your per-customer costs.  One way to defray this is to offer "concierge setup" for an additional fee.  This protects your time while allowing for you to still help customers that need it.  It also provides you with a marketing lever, as you can waive the fee for critical clients, or at high tiers of your service (your "Gold" plan or for annual payments, for example).

Is downtime a life-or-death emergency?

Obviously, all downtime is a bad time, but some are worse than others. If you run a meme-generating service, being down is frustrating to people and disrupting to you, but nobody's really being hurt by it.  Alternatively, if you run an Internet Of Things company that locks and unlocks doors over an API, if that API goes down, people could be locked out of their houses during emergencies!

People aren't always willing to pay more for critical services, especially if it's not a service they regularly think of as critical.  How many times have we all heard the story of someone losing their life's work because they didn't have decent backups?  You would think that by now everyone would have a proper backup strategy in place for important data, but unless you think about these things seriously and regularly, you may be ignorant of the necessity of paying reasonable prices or simply not willing to pay at all.

Will you spend a lot of time doing customer support?

A product that requires a lot of customer interaction can seriously limit your ability to build and grow that product and business.  Some products are just very complex and require a lot of personalized work that a certain percentage of your customers will just require help with.  These products may not be a great fit for a solo (or duo) bootstrapper – even though a solid customer support experience usually solidifies that revenue – because it's preventing you from locking in additional revenue.

This can potentially be offset by having very good documentation, videos, walkthroughs, etc.  You have to keep in mind the amount of time it takes to create these resources, obviously, but even they're not a wash, since they can be a valuable source of SEO-based traffic, if built properly.

Will this product be all-consuming?

This is kind of broad, but does this feel like the kind of product that will take over your life? Consistant customer support, regular feature requests, constant marketing, price & legal negotiations... It's important to look at the total "burden" of this product on your life and make sure it matches up with how much you're willing to give, whether that's a lot or a little.

Does the person who gets the most value out of your product control the credit card that will be used to pay for it?

If not, you don't have to just convince the primary user of the value of your software, but also have them convince their boss.  At best, this will lengthen sales cycles.  At worst, it'll trashcan sales.

Do your potential customers regularly pay for products, ideally for this kind of product?

Some customer categories love trying new things, but not so much paying for them.  Developers are a great category for trying new tools, but Linux developers aren't especially fond of paid software.  Teachers are generally happy to find anything that can save time and help them teach, but don't typically have a big budget at their disposal.  Finding a customer category that regularly spends money on the kind of software you're intending to build can make it signficantly easier to actually sell them software.

Is your market a large one with a lot of upmarket competition?

It's a lot easier to get a small piece of a large market than it is to get a large piece of a small market.  There's more momentum and, as they say, a rising tide floats all boats.  Upmarket competition shows that there's a wide variety of customer demands, which means it can be a lot easier to laser-focus onto an underserved niche and use that to jumpstart your business.

Is there demonstrated demand for a downmarket competitor?

Sometimes, the upmarket competitors just suck up all the air in the room, or it could be a product category that prohibits downmarket competitors from actually competing, due to a large minimum feature set, regulatory capture, etc.

For example, the "general-case word processor" market has a fair number of upmarket competitors, (Microsoft Word, Apple Pages, Google Docs, Open Office Writer, etc), but word processors require a very large feature set to be competitive.  Sure, maybe nobody uses more than 20% of the features of Word, but it's a different 20% for everybody.

This can be a useful opportunity to niche down, however, as while there may not be a great opportunity to compete in the general-case word processor market, there are a lot of special-case word processors, targeting fiction authors, blog authors (with built-in SEO tooling), etc.

Is the market still growing?

A growing market will support more niches than a contracting one, as well as give you more opportunities to identify and adapt your product to find product/market fit.

Is it easy to reach your audience?

This is super important.  You have to know where your audience hangs out.  What sites do they frequent?  What industry trades do they subscribe to?  What conventions or conferences do they attend?  Where do they find answers to tricky questions?  And most importantly, how do you make yourself a part of these spaces?

Some audiences are naturally prickly to any sort of advertising.  (Try posting about your startup in programming subreddits, for example.)  This is fine and actually makes a lot of sense – communities that are too friendly to advertising frequently find themselves overrun with it.  Instead, you can get ahead by genuinely becoming part of the community, giving back, and becoming known.  Then, let word-of-mouth work for you.

An audience that remains terribly difficult to reach will complicate your marketing efforts.  This can be beneficial if you have a co-founder who specializes in reaching this audience (it can be your moat), but for a solo founder, it can make life especially hard.

Is there a powerful distribution channel available to reach this market?

Sure, you can fire up a website and just serve anyone who follows your SEO trail of crumbs to your sign-up form.  But some of founders have been finding success by exploring alternative distribution channels.  For example, Heroku provides a directory of add-ons that you can search through and install with a few simple clicks.  Many Heroku developers will search there to solve their problems before they even go to Google.  If you're providing API services for developers, having your service in Heroku's add-on directory can funnel traffic to you with minimal work on your part.

There are all kinds of similar distribution channels to consider, many of them growing at a tremendous rate.  Shopify has an app store, Word Press has a whole plug-in ecosystem, Salesforce apps are well-known to support entire teams of developers.  There are definitely risks you assume when relying on distribution channels like this for your business's growth (what happens if you get kicked out from the store, or a powerful competitor shows up, or they change their API significantly when you don't have time to adapt, etc), but the boost in discoverability and distribution can be a really killer advantage.

This is obviously not a comprehensive list of things to consider, but it can hopefully help identify factors you may not have otherwise considered and make a more-informed decision.  If you'd like to find out what I end up working on next, after having wrung a few dozen ideas through this particular wringer, please consider subscribing!

Eve Echoes is the mobile version of the MMORPG Eve Online.  In it, you play as a Capsuleer, a cloned human that can pilot space ships all around a giant galaxy, mining, hunting pirates, or being a pirate yourself.  If you get blown up, you lose your ship, but not your life, and you can start again in the station you clone from.  But it still feels mighty bad to lose an expensive ship.  Nearly every ship in the game is crafted from base minerals and components, and can take a lot of time and money to build.  Getting a cool ship is an important milestone for many players, and losing that ship can be devastating.

The base of this supply chain is minerals - all ships are made from these.  And to get minerals, you have to take a mining ship out into the galaxy and mine.  This can be dangerous!  Eve Echoes is split into three zones of space: "High Security": where you are safe from all attack, "Low Security": where you can be attacked, but stations and system gates have guns that you can run to for protection, and "Null", where there is no protection at all.  And all the good minerals are out in Low or Null, so if you want to build the big ships, you need miners out in Low or Null, out where the danger is greatest.

This is a guide for those wishing to hunt miners (or be the miner) out where it's dangerous.

But... why?

Before we address how to hunt miners, we should probably talk a bit about why you'd want to hunt miners.  If they're the ones who get the minerals for all the cool ships, why wouldn't you want them to do that as efficiently as possible?

The simplest motive is profit.  Some miners carry expensive modules that you can resell to make millions, but at the very least, all miners will carry some mining lasers that tend to go for decent money.  Plus, you can fill the rest of your hold with the minerals they were mining, and sell them yourself.

Another good reason is that it also makes for a good low-stakes environment to learn fleet PvP.  Miners are slippery and can require the resources of more than one player to take down.  Miner hunting is a situation where your quarry won't generally be shooting back, but they can get away, and if they have friends to call in, you need to be ready for how to respond.  If you haven't done fleet PvP yet with your corporation, miner-hunting fleets can be a useful stepping stone towards hunting larger prey.

Finally, a great reason to hunt miners is if you yourself want to mine in that system.  Eve is a game with a memory, and if people learn that you and your corporation hunt miners in a certain system, they'll tend to clear out, and there will be less competition for the few really good asteroids in each belt.  Then, without juicy miners to hunt, other hunters will spend less time there, making it safer for you and yours to mine uninterrupted.

How To Hunt Miners

The most-important part of hunting a miner is getting a warp disruptor lock.  Miners come with between +1 and +2 built-in warp stability, so if you're only rocking a single disruptor with -1 on it, you're not going to trap anything, and they're going to escape.  Ideally you want to fit as many -2 disruptors as you can get.

Second-most important will be an afterburner or microwarpdrive.  A web goes in a mid slot, so you can't use that to keep them from getting away, so you need to be able to go fast.  If they can survive long enough to out-range your disruptor, they get away.

Lastly, choice of weapon is left up to the reader.  The most-powerful weapon you can reasonably get your hands on is preferred, but this is a miner we're talking about here.  There's not going to be anything approaching a DPS race.

With the basics out of the way, let's look at three strategies for hunting miners, from worst to awesomest:

Solo: Grab Anything, Put Points On It

For real, grab something with two or more mid slots, put as many -2 disruptors on it as it'll fit, slap a MWD on there, jam in whatever weapons you have lying around, and head out.  An Aura Warp Stabilizer grants +2 stability cold and +4 hot, so a miner can relatively cheaply have +6 stability.  That beats any solo with fewer than 3 full slots, which, guess what, is probably you, bud.

Be ready for disappointment.  And even when you win, you're not going to win anything really great.  Maybe a Mk.5 Stabilizer and some mining lasers, if they drop.

This strategy is really just if you're feeling bored and grumpy, or if you want to scare miners out of a system and can't find any friends to help.  Even then, they may not leave, because hey, you really don't pose much of a threat.

Rating: 1/5 stars.

Silent But Deadly: The Stealth Bomber

One problem in getting a whole fleet to hunt miners is that while scouting belts, you'll frequently scare off the miners before your friends can get there.  Or even if you're warping in a group, you could still warp in too far away from the miner to lock them before they flee.

An easy -- though expensive -- solution to this is for everyone involved to pick up a Stealth Bomber like a Nemesis, Hound, Purifier, or Manticore.  At time of writing, that'll cost you about 25 million ISK, plus another 30 million for the Covert Ops Cloak.  Not cheap, but bear with me.

With a Stealth Bomber, everyone involved can scout belts by themselves while remaining cloaked. This ensures that no potential targets are spooked, getting the scouting portion of the hunt done in record time.  From there, everyone can warp to the target without needing to worry about formation.  Then, it's a simple call-out once everyone is in disruptor range.  Uncloak, click "focus fire," click on all your disruptors while you're acquiring lock, and wait for the miner to die.

One important aspect of rocking a Stealth Bomber - they are made of wet cardboard.  A little stiffer than paper, but it still won't stand up in a real fight against a real warship.  You should only ever be uncloaked if you are currently fighting a miner or looting.  At all other times, you should be cloaked for safety, and also in case an unsuspecting miner warps into your belt.

Rating: 5/5 stars.

BATTLE VENTURE: BATTLE VENTURE

BATTLE VENTURE.

Who says the Venture has to be a mining ship always and forever!  Tell them to suck eggs!  Put some goddamn lasers on your Venture, put some drones in that echoing drone bay, slap some points in the mids, and go hunting!

This works best in a fleet, because solo you're going to be limited to a max of 4 points of warp disruption. You'll likely only be able to catch other Ventures that are basically AFK, but if you can't afford a Stealth Bomber, a Battle Venture is basically a cheapie cloak.  Miners tend to trust other miners, and will let you sidle on up to within disruptor range no problem.  For bonus points, start attacking when your buddies uncloak and just wait for the hate mail.

Rating: BATTLE VENTURE/5 stars.

How Not To Be Hunted

If you're a dedicated miner, you might be starting to get depressed about now.  Maybe it all seems a bit one-sided.  But there are absolutely things you can do to come out on-top, and I'd argue that things are generally weighted in your favour.  So cheer up, and read on.

PAY THE HELL ATTENTION

This is literally the most-important advice anyone will ever give you about Eve: Pay attention to the game.  If you're not watching the screen, you're giving people a free pass to blow you up, whether you're mining, ratting, or even floating at a gate you think is probably safe, I mean it's a gate right?  Nuh-uh, our CEO just blew up some poor shmuck sitting on a gate in 0.4 this afternoon.  And he did it solo.  And lived to tell about it.

So pay the hell attention.

Mine aligned

Once you're in range of all the asteroids you care about, click on a station or gate or planet or whatever, and click "Approach".  This will align your ship towards that target.  Once you're aligned, you can click the little "100%" button next to your health, and it will stop your ship.

In order to go to warp, you need two things: 1) to be pointing at your target (aligned), 2) to be going 75% of your max speed.  If you are already aligned, you save precious seconds.

Also, if you're rocking a Retriever or other large mining ship, you can put a "Higgs Anchor" rig on your ship, which reduces your top speed significantly.  This means you can start at one end of the belt, align to something on the other end of the belt, and just slowly chug along at your newly-lowered top speed.  If anything scary shows up, you can warp out as fast as you can hit that button.  Nearly perfectly safe.  Provided, of course, you are PAYING THE HELL ATTENTION.

Fit stabs

Sometimes you're not going to be able to warp out before you get locked.  Battle Ventures acquire lock exceptionally quickly, so they might getcha before you can get.  Stabilizers will save you here.

You have two options: Cheap stabs that only give +1/+1, or Aura stabs that give +2/+2.  If you're building a cheap Venture you can afford to lose (see "Play The Long Game", below), get the cheap stabs.  They'll still protect you against solo hunters for the most part.  But if you have Very Good Mining Lasers, get a couple Aura stabs.  You'll have +10 stability running hot, and it will take a very dedicated hunting group (with more than 150 million worth of disruptor hardware) to lock you down, and those don't tend to come by too frequently.

Mine With Friends

Eve is a Massively Multiplayer Online Game.  So get some other players!  If there are other miners out there with you, you stand less of a chance of getting got.  You don't have to outrun all the attacking ships, just your slow friend.

Just kidding, of course.  (Or am I?!?)  But a safer option is to get a whole bunch of friends out mining, and have a couple run guard duty in cheap destroyers.  Nothing fancy, just something just scary enough that any hunting party has to pay attention to them or risk getting hurt. This will generally deter any hunting party that isn't trying to actively claim territory.  They're there for easy fights with decent profit, not hard fights (Stealth Bombers are made of wet cardboard, remember?) that can only win them cheap modules.

Plus, hanging out with people is fun.  Try it sometime.

And the best part?  When you're hanging out and chatting with people, it tends to keep you focused on the screen so you can PAY THE HELL ATTENTION.

Play The Long Game

This is a miner's strongest tactic, and it's one most people forget about.  The game doesn't end when a fight ends, and you can't just look at a single lost ship and give up.  You have to compare your profits/losses in low/null to what you'd expect to get out of high.  Sure, in high sec, your losses will be zero, but your profits will be drastically reduced as well.  A smart miner who is PAYING THE HELL ATTENTION in low/null will make far more than a bored one in high sec, even counting the occasional ship loss.

Eve is not a game you win or lose in a day.  It is a long game, so play the long game.

Isn't This All Just A Bit Mean?

Nah.

No, I'm not just being dismissive!  I mean, yes, I'm being dismissive, but I'm not just being dismissive.  I have reasons.

See, when you go into low or null security systems, the game warns you that you can be attacked, so it's not a surprise.  You have to actually, physically consent to this possibility.  If you don't consent, you don't go out there.  You may prefer not to be attacked, but I prefer not to be sniped in Counter-Strike and it keeps happening.

And it's supposed to happen, too.  The game is built around stuff blowing up.  Without ships of all sorts blowing up on the regular, everything would be too cheap and everyone would have the very best of all things, and it would become very boring, very quickly.  The AI in this game just does not sustain a PvE-only, long-term investment of interest.  It's other players that make this game fun, yes, even other players trying to blow you up.

Finally, you have to consider that if you try to start drawing lines, the water gets very murky very quickly.  Essentially every PvP fight or action in this game is entered into because the aggressor believes the odds are in their favour.  If you went around starting fights you didn't think you could win on the regular, you'd end up very poor very quickly.  (Or maybe your YouTube channel filled with highlights of "OMG LOOK WHAT I KILLED IN A T3 DESSIE" would blow up and you'd get hella rich, I don't know.)

But the point remains that there basically are no fair fights in this game.  At least not usually intentionally, and definitely not frequently.  Even when hunting other players with weapons in anomalies, they're fitted for PvE, which requires a drastically different module set than PvP, and you have them at a distinct disadvantage.

Whether fighting other warships, stealing planetary materials, or, yes, hunting miners, you go into every fight in this game with as much of an advantage as you can secure, and expect everyone else will be as well.  Sometimes you'll win, sometimes they'll get away, but the risk makes the reward more fun, for all parties concerned.

So go out there, hunt and be hunted, have fun and PAY THE HELL ATTENTION.

Microsoft trained an Open AI Model to write Python code from comments.  It's pretty impressive:

Now, I found this in the r/programming subreddit, and there's a lot of skepticism and/or anger kicking around, but I think a lot of commenters are fundamentally missing the explicitly stated usefulness of this.  (Though to be fair, it's stated in the final couple seconds of the video, in what sounds like standard outro stuff.)  This isn't intended to try to replace programmers, but to remove the necessity of having programmers do menial tasks.

We stopped manually managing memory because it was error-prone and a poor use of programmer time, and programming jobs are still around.  We use common libraries instead of writing every line ourselves, and programming jobs are still around.  This model doesn't remove the need for programmers, it just removes a lot of menial tasks from the programmer's list of to-dos.

You still need to know how to code, as evidenced by the situations in the video where the model wasn't quite correct.  And you still need to be able to reason logically about requirements and how those become code.

As another tool in the toolbox, this could absolutely be an incredible time-saver. But it won't replace the whole toolbox.

Actually, I think it's "Heya 👋", emoji included.

If you know of or use Honeybadger to track your bugs, you'll appreciate this.  The fine folks at Honeybadger Industries just blew up the campaign emailing industry.

Instead of sending all your user data to Segment, and from there on to your email marketing solution – and spending the crazy money required for that – you can install the Heya gem, define your campaigns as Rails classes (that's right, email campaigns as code!), and you're good to go.  Set up segments directly as properties of your user models, no need to share that info with umpteen-dozen third parties (and their third parties, and their third parties) just to send an email.

It's free for open source or if you have fewer than 1k users, and only $99/year afterwards, which is wildly affordable, especially compared to literally any other competitors.

I follow their podcast (FounderQuest), and I'm eagerly awaiting updates on this. It's such a great idea, and a great way to attack the problem of campaign emailing.

For most people reading this article, the imperative programming style comes naturally, as it's the one we were taught.  It also very closely matches the simplest view of how a computer works: you give it a list of instructions and let it progress through that list in order until complete.  But just because it seems simplest at first blush, doesn't mean it's as simple as it can be.

Be kind to future you

When writing code, you will often have different priorities.  Sometimes you will write code that must perform quickly; sometimes you will write code that must constrain itself to a limited memory space.  Most frequently, you should be writing code that will be easy to read and maintain later, so clear and simple code should take priority over clever or obtuse code. Brian Kernighan puts it best: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

Thankfully, by learning a little bit of declarative programming (specifically, some functional programming), we can clean up some too-clever or too-obtuse code and make it a lot easier to read and maintain later.

A note about language

For the examples, I'll be using Javascript, since it's fantastically popular, and a language where I frequently see a lot of examples of the kind of code I'll be providing alternatives to.  It has a lot of wonderful functional programming capabilities, but it has traditionally been taught as an imperative language, since its syntax is so close to C/C++.  Don't let that stop you from applying these principles to other languages!  The constructs we'll be examining exist all over.

Example #1: How not to run a newsletter

Let's start off easy.  Assume that you need to put together some HTML for a newsletter you're planning on sending out. You want a series of paragraphs with a horizontal rule between them.  There should not be a horizontal rule before the first paragraph, or after the last.  A traditional, imperative, for-loop-based approach might look like:

const paragraphs = [
  'Welcome to my newsletter!',
  'Gosh, I hope somebody reads this someday.',
  'Hahah, this sure is unprofessional, maybe they shouldnt!',
];

let first = true;
let html = '';

for (let paragraph of paragraphs) {
  html += first ? '' : '<hr>';
  html += `<p>${paragraph}</p>`;

  first = false;
}

console.log(html);

We're iterating over all the paragraphs we want to display and adding a horizontal rule before it, but only if it's not the first paragraph being added.  This prevents us from having a horizontal rule before the first paragraph at the expense of tracking another variable.  Alternatively, we could have used a for loop that iterated over the array's indexes (for (let pIdx = 0; pIdx < paragraphs.length; pIdx++)) and checked if the index was 0, but that doesn't reduce complexity either - we still have the extra variable, and now we have to access the array by index.

Instead, we can take advantage of a functional array method available in Javascript: join():

const paragraphs = [
  'Welcome to my PAID newsletter!',
  'By reading this newsletter, you agree to send me $5.',
  'Next issue: How to charge up-front for something.',
];

const html = paragraphs.join('<hr>');

console.log(html);

Much cleaner!  join() simply sticks together the array values by the provided value, giving us the same number of horizontal rules in the same place as our array example.  But the eagle-eyed among you will likely notice a bug - the output isn't the same here.  We haven't surrounded our paragraphs with <p> tags.  Thankfully, there's another functional array method that we can take advantage of - map():

const paragraphs = [
  'Welcome to my final newsletter.',
  'We sure learned a lot on this journey, didnt we?',
  'Remember, you still owe me $5.',
];

const html = paragraphs
  .map((paragraph) => `<p>${paragraph}</p>`)
  .join('<hr>');
    
console.log(html);

All map does is it iterates over the array, applying the function we provide it to every member, and returns the new array.  Essentially, once map is complete, we have an array of our paragraphs - surrounded by <p> tags - that we then feed into the join method from before.  You'll want to be reasonably familiar with Javascript's arrow-function syntax, but there's nothing tricky going on here.

Once you know how map and join work, this example is far easier to read than the first one.  There are fewer variables to keep track of, no looping logic to mentally evaluate, and fewer conditionals to parse.  In fact, it reads fairly closely to English: "Start with our list of paragraphs, wrap them in <p> tags, and join them with <hr> tags.  Got it."  This code will be immensely simpler to maintain in the future, should you need to modify how paragraphs are displayed or broken up.

Example #2: Departments before departing

Pretend it's Monday.  You've just gotten back from the break room, cup of coffee in hand, ready to start the day.  Suddenly, your boss shows up out of nowhere.  "Debra!" he cries.  (Pretend your name is Debra.)  "Debra, I need to know how much the Garden department sold over the weekend and I only trust you to figure it out!"

So.  Typical Monday.

Thinking iteratively at first, you come up with the following solution:

const sales = [
  { department: 'Garden', price: 19.99 },
  { department: 'Automotive', price: 6.49 },
  { department: 'Garden', price: 55.55 },
  { department: 'Beach', price: 1.95 },
];

let total = 0;

for (let sale of sales) {
  if (sale.department === 'Garden') {
    total += sale.price;
  }
}

console.log(total);

Not bad!  Gets the right number, and it's not that complicated.  However, you know your boss, and you know that he's going to want some modifications as soon as he sees it, so it'd be good to have something simple and easy to modify when he does.  Taking a quick swing at it, you come up with:

const sales = [
  { department: 'Garden', price: 19.99 },
  { department: 'Automotive', price: 6.49 },
  { department: 'Garden', price: 55.55 },
  { department: 'Beach', price: 1.95 },
];

const functionalTotal = sales
  .filter((sale) => sale.department === 'Garden')
  .reduce((total, sale) => total + sale.price, 0);

console.log(functionalTotal);

Nice!  That's a bit simpler, and it takes advantage of some neat functional Javascript.  filter is an array method that takes a function as an argument and will return an array composed only of the entries of the original array that return true when passed to the function.  In our case, we're just checking the make sure that the department of the sale is Garden.  Then, we use reduce, an array method that is a little trickier, but basically just takes a function and a starting value, and the function has the current total and the array entry as parameters.  This lets us add the price of all entries to the total and return it as the result.

However, it's not the clearest, is it?  You have to do a fair bit of reading to figure out what each line does.  We could add some comments to make things clearer, but since we're passing functions to filter and reduce, and function names are self-documenting, we have a slightly more elegant solution to hand:

const sales = [
  { department: 'Garden', price: 19.99 },
  { department: 'Automotive', price: 6.49 },
  { department: 'Garden', price: 55.55 },
  { department: 'Beach', price: 1.95 },
];

const isGarden = (sale) => sale.department === 'Garden';
const addPrice = (total, sale) => total + sale.price;

const total = sales.filter(isGarden).reduce(addPrice, 0);

console.log(total);

Just as you put the finishing semicolon on there, your boss rushes past your desk, hurriedly shouting "Actually-I-need-all-the-outdoor-departments-summed-together-thanks-Debra!" before he shuts himself into a conference room with what looks like federal auditors?  Oh well, above your pay grade, you figure, and get back to your program.  After only a little tweaking, you settle on:

const sales = [
  { department: 'Garden', price: 19.99 },
  { department: 'Automotive', price: 6.49 },
  { department: 'Garden', price: 55.55 },
  { department: 'Beach', price: 1.95 },
];

const isGarden = (sale) => sale.department === 'Garden';
const isBeach = (sale) => sale.department === 'Beach';
const isOutdoor = (sale) => isGarden(sale) || isBeach(sale);
const addPrice = (total, sale) => total + sale.price;

const total = sales.filter(isOutdoor).reduce(addPrice, 0);

console.log(total);

That conditional in your original iterative attempt would have started looking a little care-worn now, and would have started fraying intensely with any more departments added in, but this pattern remains pretty clear with as many departments as you want to add.  Plus, all those isDepartment methods are pretty similar and could be moved to and exported from a module to keep this file clean.

After running it a couple times in succession to see if you can catch some stray cosmic rays hitting your processor and causing it to give out an incorrect calculation, your boss slouches out of the conference room.  "Hey Debra, nevermind that calculation.  Actually, you may as well head home for the day.  Just... make sure to take anything with you that you want to keep."

Sweet!  A day off!

The right tool

Now, it's not that you can't make clean and maintainable iterative code.  It's just that functional code leads very naturally to clean and maintainable code.  It forces you to break down your problems into smaller, discrete chunks, which are easier to reason about than one big loop.  To use a ridiculous analogy, you could use a sports car to transport building materials, but you're going to have to make a lot more trips than with a truck.  And to use an even more ridiculous analogy, you could use a truck to set a landspeed record, but you're going to have to strap a lot of propellant on there, and it'll get real dangerous, real quick.

The point is, using the right tool can make your job significantly easier.  When your job is writing code, you will most frequently be prioritizing writing clean, maintainable code.  Using a coding paradigm that lends itself naturally to that priority will benefit you in the long run.

So the next time you find yourself reaching for a for loop, consider a functional alternative, and do future you a favour.

Hey!  Are you a SaaS founder or a founder-to-be and wish you could skip all the boilerplate that comes from starting a new SaaS app?  Well I'm working on a SaaS starter kit called Nodewood that might interest you!  Save weeks or months of time and start writing business logic now!

On the most-recent episode of The Art Of Product Podcast, Derrick Reimer and Ben Orenstein chat with Rahul Vohra, co-founder and CEO of Superhuman - the fastest email experience ever made. They talk about a great many things – and you should definitely go and listen to catch them all – but I want to focus in on one important point that they spend a bit of time talking about near the start of the podcast - the importance of picking your users.

If you want to go start trialing Superhuman right now, you can't.  They're invite-only, and may continue being invite-only for a long time.  They deliberately chose that go-to-market strategy, and consider it a strong competitive advantage:

"Most companies, especially productivity companies, make the cardinal sin of making a thing and then just throwing it over the wall and seeing what happens. And the thing is, if you do that, you get two very fundamental problems.  Number one, you don’t get to pick your users, and that has its own consequences, and number two, you can’t responsibly work on their feedback."

One of the major problems with not being able to pick your users is how it can drastically slow your growth, which he expands on:

"The ... consequence of not picking  your users is that it dampens your virality and your NPS.  Let’s say that of 10k people who join in a traditional launch, only 500 of them are the type of person that you really wanted, your upper bound for your net promoters is 500/10,000, which is really really tiny.

In addition to slowing your userbase growth, it slows your learning and product development growth:

"Now the other side of this equation, and in a sense, this is almost actually even worse, is that you cannot responsibly work on their feedback. And this is a thing that hits productivity companies particularly hard, because the surface area of what we have to build is just so huge, I mean you guys could imagine what we’ve gone through in building an email experience that’s not only as good as Gmail, but in fact better, such that people not only use it, but they love it, it’s many many many years of effort. …If you just launched a thing, threw it over the wall, and people would try it, you don’t get to fix their bugs in time. In the end, you get a reputation for being slow and not listening to users, and ultimately they end up churning out.

Imagine those 9500 people out of the 10,000 in the example above who aren't really your target market, but that you've allowed in to trial your app anyway. They're none of them likely to pay you money for any significant amount of time, but they'll all have opinions about the quality of your service.  They'll have been left wanting, and that's the story they'll tell, and they'll drown out the 500 people that really, passionately love it.  Rahul puts it really well:

"So by doing it the way we’ve done it, you both get to pick your users, and you get time to work on their feedback. And by picking your users, you get more relevant feedback, you learn faster, you increase NPS, you get more authentic genuine virality with the community that matters most to you, and by working on the feedback really fast, you get a reputation for listening really closely and also maximizing retention, and most importantly, that creates a sustainable word-of-mouth growth engine.  And if you look at the heart of any successful growth story, the core driver is always word-of-mouth.

Superhuman has done absolutely no active marketing – their total marketing spend is $0 – and yet their growth has been phenomenal. Their primary driver has been word-of-mouth: 70% or more of their new weekly customers come from word of mouth from the previous week. Picking their users has enabled them to create a word-of-mouth engine that is driving hordes of passionate traffic into their waiting arms.

This isn't the only reason to choose your users (and if you're looking for more, you can always read about why You Probably Have Too Many Free Trials), but it is the most-compelling way I've heard it expressed so far.  And this is just about eight minutes of the full episode!  Ben and Derrick put some killer questions to Rahul, who has some really well thought-out answers about engineering "delight" into your app from first principles, really important metrics that they're tracking (and what those numbers are, for those statistics junkies out there), pricing research and philosophy, and how to decide what to work on, among others.

If you're not already listening to The Art of Product, this is a great episode to jump in on. It's not their standard fare – they don't usually do interviews, and instead detail their journeys while building and launching software companies – but they always have keen insights and interesting things to learn, and this episode is no exception in that regard.

You've run the numbers.  Plenty of people are hitting your marketing site, plenty of people are signing up for free trials.  The problem is conversion - maybe 3% of your trial users convert to paying user.  Maybe less.

You tried playing around with the payment form.  That didn't work.  You tried adding an onboarding tutorial.  That didn't work.  You even tried adding a phone number to your help section.  That moved the needle a bit, but not nearly enough!  Clearly you're missing something, something that will make a real dent in this conversion rate.  But what it is?

You probably have too many free trials.

Set Expectations

It might seem counter-intuitive, the idea of reducing your number of trials.  You worked so hard to get that traffic and get those trials.  Why throw all that work away? Well, let's examine an extreme case, to help prove the point.

Pretend you've written some invoicing software, designed to allow your users to send invoices and receive payment.  Thing is, you can only send invoices by email, and you can only accept payment through PayPal after a 30-day anti-fraud confirmation period.  Oh, and you can only send invoices to people in New Zealand.  It's a tax thing, don't ask.

Now, in this example, your website doesn't mention any one of these facts because you're scared about chasing off potential trial users.  Since you're optimizing for trials, that's what you get.  Just hundreds and hundred of trials pouring into your system every month.  This would be great, except that your Trial-to-Paid Conversion rate is hovering around 1%.  Considering you're spending a bundle of money on an affiliate program to get a good chunk of those trials, that's not sustainable.

So what do you do?  You could try all kinds of things to try to raise that percentage, but those efforts will be unfocused and misleading.  Your real problem isn't your Trial-to-Paid Conversion rate, your real problem is that you don't know what your real problem is.

In order to even have a chance of knowing what you need to do to improve your conversion rate, you need to know your trial users and the problems they're encountering. With so many trial users with so many different intents and expectations, it's really difficult – if not impossible – to properly identify the core problems that need fixing.  In fact, it's arguable that your Trial-to-Paid Conversion rate isn't even 1%, because the trials you're accepting haven't been properly qualified – they're almost no better than random people off the street.

If you play poker, think of it like Texas Hold 'Em.  If you played every hand set in front of you, you'd lose a lot of money on the bad hands.  That's why pros only play hands with a good percentage of winning, to conserve resources for the best opportunities to make money.  (If you don't play poker, please skip the preceding paragraph.)

But maybe it still seems a bit academic to you.  Who cares if some made-up number is higher or lower? If 10 people sign up, who cares if they came from 100 trials or 1,000?  What if you just don't give a good gosh-dang what that number on your spreadsheet says?  Well, it turns out that there are:

All kinds of great reasons to pre-qualify your trials

Surprise!  Turns out we're doing this for a reason. Actually a whole bunch of reasons.  Let's check 'em out.

Building trust

When a visitor first hits your site, they likely have a minimum amount of trust in you.  It's possible they found out about you because they're ardent listeners of your startup podcast, but it's more likely that they found you off Google or from an article on your blog. Given that they don't know a whole lot about you, they likely don't trust you all that much, either.  Gaining that trust is essential in order to get them to sign up for your service, especially if you require a credit card up-front.

Setting expectations about what's involved in using your service is a great way to earn that trust.  Sure, you might lose out on a few potential trials from users who don't meet those qualifications (more about what to do about that later), but you might actually increase the number of trials you get from users who do meet those qualifications.  Since those users are way more likely to convert, it's a big win.

Quicker conversions

Properly pre-qualified trials have had a great many of their objections addressed before even starting their trial, and so don't need to spend precious trial time trying to find answers to those questions.  This means they tend to convert quicker, which means you have to spend less time performing high-touch sales or customer support, and you begin earning your recurring revenue sooner.

Easier to predict

When trying to run metrics and make predictions, you'll find that it is much easier to predict the Trial-to-Paid Conversion rate of carefully qualified trials, whereas unqualified trials will have a much broader range.  When trying to calculate things like monthly run rate, customer lifetime value, or if you can afford to keep acquiring customers at your current spend rate, knowing this number more accurately can be invaluable.

Avoiding being spread too thin

Having a lot of trials means having less time for each.  This significantly reduces the amount of care and conversion efforts you can put into helping each trial, especially if you offer concierge onboarding or if your application requires a lot of hands-on sales or customer service during your trial period.

This can be mitigated by automating some of your conversion activities (like setting up automated lifecycle emails, something we'll talk about in a later article) and creating a clear, accurate, and up-to-date knowledge base for you to refer customers to when they have questions.  Additionally, you can set up community tools like a forum or Slack/Discord server where your users can help each other (though those have an ongoing cost of their own).

That said, all of these activities are investments, requiring up-front work before they'll pay off, and if you already have too many trials to spend sufficient time on each already, you may find it difficult to find the time to spend building these tools.

Selling or taking investment

Aside from just having inspiring metrics to post on Indie Hackers, you're going to want to have a solid conversion rate if you ever want to sell your company or take investment.  A good rule of thumb for conversion rates is between 5-15% if you don't require a credit card up front, and between 40-60% if you do require one.  Your New Zealand-centric, 30-day delay, Paypal-only, email-only invoice company will never hit those numbers so long as you're not properly qualifying your trials. Investors will notice, and while not every investor will be a stickler for the rules, anything hinky could cause them to back off or reduce their offer.

Okay, so if you are in a situation where you're letting in a lot of unqualified trials (which you now know why is a bad thing), what exactly can you do?  Thankfully, there are a variety of options that can be explored, with a range of time investment and bravery required.

Bravery?  That's right. You're going to see trial numbers go down, and important metrics going down can be scary!  But you have to hang on and evaluate what happens to your trial conversions, your customer LTV, your churn, and all the follow-on numbers before you balk.  With some careful effort and a little luck (which is required for nearly every serious endeavour), you can lower the number of poorly-qualified trials you accept while seriously improving the health of your business.

How to pre-qualify customers

Be clear about your service

Let your customers know about your service, warts and all! I mean, obviously don't tell them about the weird bubble-gum and duct-tape behind-the-scenes scripts you have that run statistics calculations every night. Every service of some note has technical debt they'd love to get around to but haven't found time yet, but that's not anything that customers need to know about.  You mainly need to let them know about the features you have as well as the ones you don't have.

There are good ways to do this, and there are bad ways to do this.  A bad way would be to list on your front page, above the fold, all the countries you don't offer service to.  Another bad way would be to make the information available, but buried deep in the fine print of a hard-to-find knowledge base article.  But a good way would be to turn a weakness into a strength.

For the example above of the invoicing software that only works in New Zealand, well, that's a differentiator you can market on.  The Big Guys offer service internationally and focus on the USA or EU.  New Zealand won't ever be a priority to them, but it is your top and only priority.  Let people know that!

That's a little harder to do with your other limitations, but still possible.  Instead of explaining sheepishly over customer service emails that users will have to wait 30 days to accept payments to ensure nobody is scamming anybody, you can boast about your commitments to fighting fraud on the sign-up form.  That said, this is more of a product limitation you would be better-served by working on fixing than marketing.  You have to be able to tell the difference.

Don't starve your users for information, either.  Offer screenshots and video explaining your most-valuable offerings, and PDF whitepapers about successful customer cases if you have them.  You don't want to clutter your home page, but that's what links are for.  Make sure the information is available for interested researchers.  Frequently, the people browsing your site won't be actual purchasers, but people looking to convince their bosses to purchase.  Make sure to give those people ammunition.

Be up-front about your requirements

If you bought a video game and got it home and installed, only to discover that it requires a video card released literally yesterday in order to play at a decent framerate, you'd be upset, right? Well, the same goes for users of your service. If you can only accept payments through PayPal, don't hide that fact. Again, you don't have to advertise it front and centre, but it shouldn't be obscured until after your customer is five days into their trial and trying to accept payment on an invoice.

Be up-front about customer investment

If it takes your customers a solid forty minutes to fully set up their trial account, don't go around promising them "setup in a snap" or similar lies. By being honest (or at least reasonably honest, you don't have to list the exact average number of minutes required), you allow your customers to plan their investment in your trials. Someone expecting a ten-minute trial might kick things off just before a meeting or getting back from lunch.  Going beyond that might mean they wander off, never to return.

If you have a service that has an API that people integrate with, you can save them a lot of time by letting them know what's involved in that integration.  Make your developer docs publicly available instead of behind a paywall or on a frequently-outdated PDF that you email to customers that remember to ask.  This can allow people to schedule their trial when they have time to perform the integration, as well as increasing trust, along with the likelihood that they'll begin a trial at all.

Be up-front about your prices! Sure, for Enterprise levels where you need to hammer out custom service agreements and do custom paperwork, you can require a phone call/email/videoconference/carrier pigeon.  But for "regular business" levels, make sure that your prices are available and the differences between tiers are clear and easily understandable. I'll be writing more on creating clear & effective pricing tiers at a later date, but at a minimum, make sure your prices are available and sensible.

Build a knowledge base

Whether this takes the form of a simple FAQ page or an in-depth, tagged, searchable, illustrated, accessibility-oriented, mail-orderable knowledge base system, you should make the answers to common questions and objections available publicly. Not only will this help you qualify customers who might have limitations that they'd otherwise have to take a chance on, but it will help build trust with customers who do qualify.

Actually, it helps build trust with customers who don't qualify as well.  There are all kinds of examples I can personally think of where a service wasn't available in Canada, and I was able to come back and check on them (or sign up for a mailing list or follow them on Twitter - more on that later!) until they did finally launch.

A well-written knowledge base also helps reduce your customer service load as well. Many customers will choose to self-help, and if they can search and find their answer already written for them on your site, that saves both of you potentially lots of time and effort. Even for customers that don't choose to self-help, you can email them a link to the appropriate KB article, which is way quicker than writing out the same answer over and over.  Plus, you can update the article with new information as it becomes available, improving its value over time.

Consider a chat widget

Some people love 'em, some hate 'em, but they can be very effective if you have the time to tend to them. Getting real-time feedback on questions or objectives you may have is very convincing to a lot of people, but if you don't have the free time to reply (or are in a different time-zone than your target market), the fact that there is a chat widget right there and that it doesn't seem to do anything can be more frustrating that fulfilling.

Many chat widgets now integrate into Slack, letting you know with @channel announcements when someone has a question.  If you have a remote team already using Slack, spread out over a few different time zones, this can be an ideal way to make sure that the chat widget is always attended.

Consider requiring a credit card

Okay, this is the big scary one. While requiring a credit card can seriously reduce your Visit-to-Trial Conversion rates (from 10-20% down to 0.5-2%), it definitely signifies serious intent, and if you don't have a strong trial conversion process in place, you may not be converting too many customers that didn't have serious intent in the first place.

While those numbers may be spooky, this is also the biggest "win" in terms of qualifying your trials.  If someone enters a credit card, it indicates that you are not only dealing with someone who is seriously considering purchasing your service, you're also dealing with someone who is capable of it.  Very frequently, it can be difficult to ensure that you are in contact with someone who is not just interested in your software, but has the authority to spend money on it. If they already have or have secured access to a credit card, you can be almost guaranteed that they are authorized to pull the trigger if you convince them.

One thing you'll need to be certain of before going down this route is that you have sufficient information on your sales site for potential customers to make that that commitment. You need to make the value of your service clear before asking for a credit card, or people will bounce off you into low-earth orbit, never to be seen again. If you've already implemented the stuff in the rest of this article then you're off to a good start, but there's always room to improve.

It's also important to keep in mind that this suggestion isn't always strictly necessary!  (In point of fact, none are strictly necessary, but many of them can be good to evaluate, at least.) Not every audience or service will need action this drastic, and there's research showing that having credit card-less trials results in higher overall conversion. But if you've gotten yourself into a situation where you have incredibly poorly-qualified trials, it may call for drastic action. Growing your trial numbers doesn't really help if those trials aren't likely to convert.  Get your trial quality under control, then go back to trying to grow those numbers.

Don't throw those "bad fit" trials away

Just because some of your users may not be ready to start a trial (at least not one they're likely to convert from), doesn't mean you should throw them away. While some visitors will bounce off your site because they've determined that they're a bad fit for you, a great many of them just aren't ready for you yet. They may be anticipating an upcoming business need, or waiting for you to hit that particular combination of features they require, or simply be in the process of getting educated about your industry, and don't yet recognize that they need you.

Offer alternative conversion avenues for visitors like this.  Set up a mailing list, Twitter, Facebook, Slack, Discord, YouTube channel, or heck, even Twitch stream, and point your less-engaged visitors that way. Make sure they have the ability to continue to engage with you as you grow, and when they're ready to have a go, they'll remember where you are and what you do.

You want to try to direct your visitors to the most-appropriate location, based on their level of interest and likelihood of converting.  If they're ready to rock and roll, send them to the signup page.  If they need more information, make sure you have the required information easily-available on-site and in supplemental locations (YouTube channels, Medium posts, etc). If they require more hands-on interaction, consider offering demos or running webinars. And if they're just kicking the tires, make sure to "give them your card" so they can come back when they're more serious.

Improving from here

After a significant round of improvements, KiwiCharge, as you've now re-christened your New Zealand-centric invoice sending service, has some much healthier numbers. Instead of hundreds of trials every month, you pull in around a hundred.  You've significantly lowered the affiliate payout for trials, but increased the payout for converted trials, and the quality of the visitors they've sent your way has improved substantially. You're still not requiring credit cards, but your Trial-to-Paid Conversion rate is hovering around 9%. Better than that, your absolute number of conversions is actually higher than before! Combine this with a lower cost per trial and a lower churn rate from users encountering frustrating limits months after they've signed up, and your financials have never looked better.

You can be confident now that a sudden spike in visitors from a press release or popular article will properly segment the traffic into trials, newsletters, and your very popular Twitch stream, and won't lower your Trial-to-Paid Conversion rate for that cohort of users significantly. Even better, you're starting to get coherent feedback from the users who don't convert: Only being able to accept payments from PayPal is a real pain point, so you've prioritized your other gateway integrations, and should be launching Stripe, Chargebee, and Authorize.net within a month.

Matthew Ström, design lead at Bit.ly, is also picking up the torch and warning about in-product messaging (aka what a lot of people think about when they think about user onboarding).  He correctly calls out the potential opportunity cost of getting locked-in to a bad design when using in-product messaging to fix things, but takes a different tack about it than I did.  His point is less about calcifying a bad design with hard-to-change tooltips, and more about obscuring the fact that it's a bad design decision in the first place.

Frequently, these tools are used by marketing departments to pursue marketing goals.  When one of those goals is "conversion" and your product/development team is not also given that same goal, your marketing team can use these tools to shore up problems without the development team ever getting involved.  This seems great, except for the fact that it's a band-aid fix.  Your product team is now unaware of the problem in the first place, and can't resolve it.  Because they never fix it, the tool-tip bandaids become a permanent fixture and further features now have to have them to not stand out.  Your product is permanently more complex and the underlying usability issues remain and are perpetuated forward.

I heartily recommend reading the article for yourself.  He goes into some wonderful real-world examples of where this kind of thinking leads to, some that I've experienced and continue to be frustrated about, others that are new to me.

It's easy to get lost in metrics.  You've got A/B tests, time series tests, keyword tests, every kind of test you can think of.  You're measuring engagement, clickthrough, funnel progress, time-on-site, everything.  You know every number related to your customer by heart, backwards, and blindfolded.  But do you really know who your customers actually are?  Do you really care?

It's very easy to argue for things that increase profits.  Everybody loves profits.  But it can often be short-sighted.  For instance, it became par for the course to for a customer support call to go to a call centre in a country that offered competitive pricing.  The agents you spoke with were rarely actually part of the company you were calling and instead were handling support for multiple companies at once, a stack of binders with each company's scripts and regulations at their side.  They were almost never knowledgable or empowered enough to solve anything other than the most rudimentary problems, and required multiple levels of escalation to even have a hope of getting anything accomplished.

But those call centres, and those jobs, are moving back.  Never mind that it's much more expensive to run a customer support center in the USA - there's more to it than just simple cost.  Customers that are well taken care of are more loyal, stay longer, tend to pay more, and recommend you to their friends and family more frequently.  These things can be more difficult to track than a simple cost-saving calculation, but nonetheless are incredibly powerful.  Maybe you're spending more on customer service than you were when it was outsourced, but the business is growing again, and people aren't spending time and energy writing hit pieces against you.

I guess we just throw out all these numbers, huh?

There's no need to be so dramatic. You put good time and effort into setting up that data-collection empire, and it would be a shame for it to go to waste.  But it would also be a shame to let your customers go to waste.  The key, as in all things, is balance.

In the past, I have argued for shorter trials, or even removing your paid trial entirely, and moving to a money-back guarantee.  I still stand by these as potentially good ideas, depending on what stage you're at and what goals you have for growth. Then I was reminded that you can be too aggressive with this.  Every customer you turn away because you have a paid trial instead of a free one, or because you require a credit card, or because your trial period is shorter than they're comfortable with, is a customer that you can't interact with, and ultimately, can't sell to.

If you're not interacting with customers and potential customers because that's "not scaleable", you're missing out on potentially critical feedback about your service, and potentially huge amounts of sales.  Don't automate yourself away from customers completely.

So should I be doing big up-front sales?

If you mean steaks and scotches, "business trips" to Vegas, that kind of thing, probably not.  Not unless you're selling to massive enterprises and you've got an expense account as deep as the Mariana Trench.  But if you mean early-pipeline contact, phone calls, video calls, and emails, maybe!

Nathan Barry has an excellent piece on how direct sales are critical to the growth of a SaaS business, and given that he's running the fantastically-successful ConvertKit, he's probably right! But you have to be careful to make sure you show value early.  A big up-front sales process is a lot to ask of a potential customer.  They've got a business of their own to run, and here you come asking them to invest their time evaluating your service, which may or may not solve a problem they're having.  It's a gamble for them, and you have to recognize and show empathy about that.

Which brings us back to respect.

This has been a lot of contradictory advice.

Right! Because there's no one-size-fits-all piece of advice when it comes to your customers and your business.  There's no magical set of settings you can tune your service to that will guarantee success and fame.  You have to get to know your market and get to know your customers, then evaluate and decide on your course of action from there.

It's important to track the data around your customers and their use and evaluation of your service, but it's also important to remember that these are real people, not just a faceless set of data.  They have goals they want to accomplish, and they're hoping your service will be the one that helps them do so.  Don't know what their goals are?  Ask!  Then follow up, to make sure they're still achieving success as time goes on.

Look, Google is gradually entering every possible service space (and then leaving, just as quickly, it seems).  If people wanted to get ignored and treated like just another wallet, they could go to Google, or Amazon, or Salesforce, or whatever massive company that doesn't spend enough time on their customers that you love to hate on the most.  You have a chance to be different and to stand out from the massive corporations, to show that you really care.

I get it, there's a lot to do when running your own business.  It seems you're always splitting your time between thirty different top-priority things.  But if you don't make time for your users, to really show them the respect they deserve, you're missing out.  They could churn out, not convert at all, never even try your service, or even turn into an anti-fan, telling everyone they know about how poorly they were treated by you.

You don't have to ignore the metrics, but you can't ignore your users.  Keep them in mind when making critical decisions.  Respect them, and be worthy of their respect. Then instead of hit pieces, maybe they'll write some glowing praise.