My response to them is also the point of this blog post:

"It's unethical to offer to pay me personally as a way to influence purchasing decisions on behalf of my employer. Do better."

There are three problems with this approach to sales:

1. It's unethical. This seems to be the low-stakes SaaS version of pharmaceutical reps paying for doctors to go on vacation. But ethics aren't dependent on how life saving something is. Regardless of the stakes, it's unethical to pay someone privately while they're representing their employer or are being trusted to be impartial. Even if it's as small as $50, it's a conflict of interest.
2. It will blow up on you. If you have someone accept it and then their employer finds out, good luck closing that deal!
3. It makes you look bad. If I've never heard of you before, my first impression is that you are desperate. It's a bad look.

I'll admit, there are some grey areas. For example, if you're sending this to someone that owns the company outright then there wouldn't be an inherent conflict of interest. But, by and large, this is ethically wrong and everyone should stop doing this.

While we're here, also feel free to stop cold pitching me. That's not ethics advice, that's just a plea to save my inbox.

Updated List (companies that sent these offers):

• Galactic Fed, 07/12/24
• Premier Soft, 07/17/24
• NetSpring, 09/10/24

Footnotes: Gift cards as an incentive aren't always bad — it's when they're confusing your personal vs. professional roles. For example, a gift card for a personal G2 review or research initiative has no conflict.

Fortunately, I'm quite handy and for the things I don't already know how to do, I'm able to YouTube-tutorial my way to success. Many of my fellow homeowners aren't though and they use a solution that should have a parallel in software development.

That solution is to call a handyman. They know someone who is familiar with how things are done, can come in over an afternoon, look at how stuff is set up, and get it working in the way the owner wants.

My question is: wouldn't it be great if this was possible with software?

Now, before everyone gets upset with my trivializing software development what I'm not saying is that we should just have all software development done part time. Like in buildings there are hundreds of thousands of people who are fully dedicated to developing systems, tools, parts, building codes, and processes. These are all essential for the handyman to work on top of. There's no real replacement for having a dedicated team of highly invested and capable engineers building things.

However, it seems like there's plenty of adjustments that should be able to be made without having the most highly educated (and paid) engineer in the world come in and make the change.

What I imagine is that there would be a certain class of software handyman available for the odd jobs. To keep with the housing analogy, there would be people who know how to wire a light switch but aren't electricians. They can fix a leaky faucet but aren't a plumber. They can unstick a broken flue but aren't chimney smiths. In the original sense, they are jacks of all trades and masters of none. They can get things done but also know when something is beyond them.

One of the key distinctions here is that these are people who are not trying to build a big business or brand. They don't have employees, they work mostly in cash, and bill hourly. They are fundamentally different than, say, getting 5 quotes from different roofing companies before having a team show up to take on a major project.

Wouldn't it be wonderful if this existed as a category in software development? We have things close to it for fractional, contract developers through systems like Gun.io, Toptal, etc. But as far as I'm aware, there's not something out there that connects you with a regular handyman who can just pop in and accomplish tasks for you.

The difficulty as I see it is that so much software is extremely customized. But for common tech stacks — Supabase/React, for example — there should be a class of person who is known to just be able to jump in and take on some tasks without spending weeks onboarding.

If such a thing exists, please let me know! And if it doesn't, would you consider facilitating it?

Footnote: There are also plenty of things I don't do. We needed to get the connection from our electrical panel to the street upgraded so we could install a low-temperature heat pump. You better believe I did neither of those things!

Today, though, you can jump between a dozen different sites and feel like you're wandering different aisles in the same grocery store. The inventory might be different, but there's no change in how they make you feel. Why is that the case now when it wasn't the case a decade ago?

It's my position that it's due to:

1. An over-correction away from meaningless skeuomorphism, and
2. A scale-at-all-costs mentality that has saturated the software world.

Let's dig into both of these, how they've combined to create our current landscape, and where to look for a better future.

Meaningless Skeuomorphism

When I consider a design problem, I use a rough model in my head to organize what I'm trying to create. I may not always be explicit about it, but all software features end up organized like this:

1. Culture: What are the assumptions you can make about the intended users?
2. Element: What is the activity you want to enable for the user?
3. Form: What is the method you'll use to display the activity?

We have a simple and easy-to-understand example by looking at the bass-adjustment feature in Logic Pro:

You'll notice that the culture and element could've taken on any number of forms. A toggle, a number-input, a slider, or some other clever adaptation of a physical input. All of those would have been fine! But what makes this a first-rate design is that the form pulls directly from the culture, without obfuscating the element.

For a contrasting example, let's look at the pre-iOS 7 Notes app on iPhone. In particular let's look at the header:

It's hard to see, but that little pixelated bottom-shadow is actually a simulated torn piece of paper. This is going after the effect that you have with a physical yellow legal pad when you tear a page off and part of it remains suck to the binding. To the designer's credit, they did a great job of replicating that real-world effect. But let's consider it through the model above:

1. Culture: People who want to take quick, locally-stored notes on their phone.
2. Element: A navigation header that will appear at the top of all notes in any state.
3. Form: Torn paper that indicates a note has been removed.

As part of the top-level navigation header, this decoration is extremely prominent. Yet, we see a breakdown between element and form. It's a form that takes away from the element by confusing the user. Is it indicating a note has been removed? That there are a limited number of notes before you run out of space? That these notes have a fixed width and height? Nope! Just a decoration!

I don't want to obsess too much over this one detail. Rather, I bring it up because by 2012 there was a growing frustration with the decorative skeuomorphism of iOS driven by features like this. As the most influential platform, the design language had (and has) a large influence on broader software design trends. So, when iOS 7 was released, it provoked a titanic correction away from meaningless skeuomorphism that was rightly celebrated.

The future was clear: decorative flourish was out, flat was in. Crisp lines replaced faux leather. A world of undiscovered beauty was ahead, waiting only to be charted by intrepid designers. It would have been beautiful if not for the economic conditions it collided with.

The Cost of Scaling

As has been discussed widely, the 2010's brought VC firms with massive funds, an incredible number of deals, and eye-popping valuations. The underlying premise was that firms just needed a couple of big wins to make their funds work, even if 99% of their portfolio went bankrupt. This inherent pressure caused niche businesses to try to adopt a model that shot for a unicorn valuation that realistically should've just been a healthy lifestyle business.

How does this tie into the evolution of software design over the last decade? By warping the intended audience of most software. We had seen a reset on Element and Form made popular by Apple's iOS 7 update. The reset of Culture was driven by VC firms.

There are very few forms that are universally appropriate for the entire world. As an example, let's stick with note-taking. The yellow legal pad is popular in the United States. Yet, Japan is famous for a completely different style of notepad (I'm an ardent Mnemosyne-user, personally). Meanwhile, in Germany, you have notebooks like Hahnemühle's Iconic. If you were making a notes app for any of these cultures, you'd likely embrace a different form depending on what was already popular. The element (note-taking) may be static, but the form would be changed by the culture.

When it comes to scale-at-all-costs, there is an inherent assumption that your audience is — at least — all of North America, and for most startups there's some long-term vision of "the entire world." There aren't many paths to getting investment without promising an eventual exit in the billions, and there aren't many ways to chart that path to 10-figures without making the entire world your market. While that looks great in a pitch deck, it implicitly changes the design framework. It takes the breadth of possible cultures and flattens them into a mono-culture.

The end result is unavoidable: without unique culture inputs, form outputs will converge.

Over the last decade we've had a hard — but fair — correction away from skeuomorphism driven by a combination of better hardware, different taste, and bad memories of faux-leather. At the same time, we've had a generation of companies assume that everyone is a potential customer and that a culturally-specific form has no upside.

What this does is make everything feel the same even if the element is completely different. You have a world of websites that are all roughly the same few colors because they're found to be universally acceptable. You have businesses that have nothing in common with each other, but when you go to their apps they feel the same. If you spend more than a few minutes using the most popular platforms and tools you've experienced this.

To put a point on this: it's boring.

The Promising Exceptions

Yet, even as you've been reading you've likely thought of exceptions. And you're right! There are beautiful apps and websites that have come out that buck this trend. Two that come to mind are Playdate and Orion. They're wonderful examples of technology that embrace charm. Yet, though I don't know the creators of either, I think it's safe to assume that they aren't pursuing some billion-dollar valuation.

Which I think points to where the great designs are going to come from. They're going to come from teams that aren't focused on being universally popular, that are going to make opinionated decisions that they know will be unpopular with some people, and they're going to be in niche verticals. Which is why if you want to explore innovative and compelling design those are the teams you'll want to gravitate towards.

Note: I'm not a designer, but I do think about it a lot. Get in touch with your own opinions! Trevoragilbert [at] gmail [dot] com.

When I tinkered with technology as a kid, I was learning how computers work. I wasn't learning from classes or books, I was learning by flipping a switch and seeing what happened. Or, I was learning by wanting the computer to do something, knowing it was able to do it, and then browsing the depth of 1996 forums until I found something that did it.

How did I learn about basic networking? It wasn't by some Khan Academy course someone put together to teach people how data moved over cables, the basics of packet switching, and the history of TCP/IP. No, it was because we had two computers, both of them had Age of Empires on them, and I wanted to play against my brother. So, I needed to figure out how LAN works, how to configure a network card, what a firewall was, etc. (Shoutout to my sister who I also "played against.")

How did I learn about cloud storage? Well, I wanted to get a copy of Photoshop but I was probably ~8 so I obviously didn't have the money to buy a copy of it. Upset that I wasn't going to be able to edit whatever image I was working on, I moved on to some other corner of the web. There, I learned about this thing called FTP. I learned that http: did one thing and ftp: did something else. So, fresh with this knowledge and still upset that I didn't have Photoshop, I experimentally put in ftp://www.adobe.com. To my astonishment, there was a list of all of the most recent releases of Adobe's software. I was able to queue up a download of Photoshop and I was off to the proverbial races with our 56 kbit/s dial-up speeds. Along the way I learned about file trees, how to store files online, and also the thrill of finding something that wasn't public knowledge. (Yes, I just checked and this doesn't do anything anymore.)

How did I learn to make websites? Using my incredible skills highlighted above, I booted up Frontpage on our family desktop and started to poke around. It was a tool that made things easier for the user, but it didn't lose the ability to get into the code and try out different things. I was able to bold something using the editor and then click over to the code and see that it did it using <b>. I was able to see what was happening and learn how to do it without guardrails. Was it great? No! It was terrible, the websites looked awful. But I did learn how websites worked.

What do all of these things have in common with each other? They were tinkering neutral. They weren't designed from the ground-up to have people tinkering in them. But they also didn't discourage tinkering. They tried to make things as easy on the user as possible, but they also recognized that the software designer is never going to be able to account for every conceivable edge case or user need. Whether the designers were self-consciously neutral or just didn't care to lock it down, there weren't locks on everything. And when you're just starting to learn, a closed-but-unlocked door is an invitation to explore.

That's sadly less the case nowadays. There's a certain pride of "I know what needs to be built and everything else will be locked down" in today's software. Some of that comes from valid security, trust, safety, and privacy concerns. But much of it is unnecessary. It's in those unnecessary constraints that we losing the freedom to explore.

When it came to bringing in new leads in a highly competitive market, we had three main curbs to keep in mind:

1. Be Creative: We were competing with a ton of other companies in the same space with multiples of our funding. This was right around when Brexit happened and caused historically-low mortgage rates to go even lower. There was a competitive frenzy and we had to be very selective in how we picked our growth battles.

2. Be Scrappy: Our competition covered the spectrum from giants like Wells Fargo to well-funded startups like Better to the entire world of small town banks that did a couple of refinances a month. We would never have the same funding as the bigger players and it would take years to build a recognizable brand. So, we had to figure out where the edge cases were that we could exploit.

3. Control Any Success: One of the biggest constraints was that we couldn't bring in too much business at once. Because each piece of potential business needed a ton of hand-holding from Sales, Compliance, Operations, Secondary, etc. we couldn't just open the floodgates to any-and-all business. So while we were tasked with profitable growth, we needed to be able to selectively stop that growth.

These constraints led us to a mix of channels that was dominated by lead purchases from LendingTree. For awhile, I was tasked with making sure we got the most out of them.

How LendingTree Worked

From a 10,000ft level, the way LendingTree works is that consumers search for something like "mortgage refinance," LendingTree directs all of their ad traffic from those terms to a very efficient landing page where they collect data on what the consumer is looking for, and then LendingTree "matches" that consumer to a partner finance firm. That matching is really just an auction of loan providers where they tell LendingTree how many leads they want, how much they're willing to pay, and key characteristics they want those leads to have. The consumer's information is then sold to 4-6 companies who then — typically — spam them via phone, email, and text.

Unfortunately, for a company working with LendingTree the process worked by emailing Excel templates back-and-forth with our account manager. In such a manual system there aren't many levers for optimization. What we did have though were the following criteria: zip code, loan amount, loan-to-value (LTV), credit score, bankruptcy/foreclosure data, home type, and whether they've been in the military.

For those that haven't worked in the mortgage industry you may be thinking, "ah, I'd go for the leads that have the best credit score in the most well-off zip codes." Congratulations! You just reinvented redlining. Which brings us to the last constraint: don't break the law. Which is generally speaking always a constraint, but in the context of the mortgage industry is sometimes challenging to know whether you're abiding by it so there's typically an overabundance of caution.

Optimizing What Shouldn't Be Optimized

As a reminder: we needed to grow in a controlled way, we needed to be creative without risk, and we needed to optimize without breaking the law.

What I ended up doing was building a maximum profitability calculator on my laptop. The way it worked is that once a week I'd run a script that took our recent closed leads with their attributes, see how much money we made off of each one, and calculated the expected value of similar leads with the same characteristics. (We couldn't be too specific without crossing into questionable territory, so we did it in tranches instead.) We'd end up with results like:

Loan Amount |  LTV |  Maximum Price
------------+------+---------------
$200-350    |  40  |  $40
$200-350    |  70  |  $70
$350-450    |  40  |  $45
$350-450    |  70  |  $40
$450-550    |  40  |  $60
$450-550    |  70  |  $50
$550-660    |  40  |  $70
$550-660    |  70  |  $75
$660+       |  40  |  $45
$660+       |  70  |  $65
...         |  ... |  ...

It was an exciting find! (In reality, the results were more detailed, but this was ~10 years ago and I don't have the script anymore.) Contrary to common expectation it wasn't a linear function based on loan value and credit score. Rather, because different categories were competitive for different reasons we were able to compete at seemingly random tranches more effectively than other lead buyers.

This was touted as a win because we were now optimizing one of our main lead channels more effectively. It was also pretty satisfying to just build something like this myself, scratching an itch for building software I didn't know I had at the time.

The downside, though, was a way of thinking that is all too common at startups. That if we take our current approach and just become much more efficient at it, we'll win. It's all too common for that mindset to turn into local optimizations that never lead to leveling up. And before you know it, you've burned through your runway and are asking yourself the question, "why didn't we spend our time and resources on a grander bet?"