Give us a ring to talk about it.

Give us a ring

Thanks for reading!

—Jon Christensen
CEO, Kelsus

Let's talk about it

Looking forward to reconnecting if we haven’t talked in awhile!

Thanks for reading.

—Jon Christensen
CEO, Kelsus

I get it. You’re in Cursor, you’ve got Claude Code or Codex as your copilot, and you just built a pretty solid appointment scheduler in an afternoon. You’re not even a developer! So when your engineering team comes back with a three-week estimate for basically the same thing, you’re thinking: Are they just not using AI right?

Yes. They are. But something subtle changed that both sides missed, and it’s making your dev team look slower than they actually are.

From the developers’ perspective, their estimates still feel accurate. They’re hitting their timelines. The old estimation techniques still work. Three weeks ago they said “three weeks,” and here we are, shipping on time. So what’s the problem?

The defense that doesn’t work

The standard developer responses to “why so slow?” all sound like excuses now:

• “Did you read all the vibed code?” (Sure, a few more hours.)

• “What about security, logging, monitoring?” (Okay, add a day.)

• “Where’s CI/CD?” (Another day, fine.)

Even if you price those in generously, we’re still not looking at weeks of full-time work. So the question stands: if AI makes coding faster, why aren’t dev teams getting proportionally faster?

Because we forgot to notice what changed about scope.

Pre-vibe vs post-vibe: what actually changed

Before vibe coding came along, there was a constant tension between dev teams and product teams over scope creep. We’d wrestle. Product wanted polish; engineering forced descoping to hit dates. Every week we’d argue about whether some nice-to-have was worth pushing the deadline. We’d say things like:

“Are you sure that’ll help us sell more seats?”

“Will users actually use that?”

“Can we just ship the core feature first and see if anyone asks for that?”

These days? We just .. say yes.

A product manager floats the idea that the appointment scheduler should have three different user-driven configuration options. Instead of pushing back, we do the math in our heads: That’s maybe a few more hours of vibe coding. Easier to say yes than argue. So we say sure.

The developers aren’t lying about their estimates or padding them. They genuinely don’t realize they’re building more than they used to. The old estimation techniques (story points, t-shirt sizes, past velocity) still produce accurate timelines because they’re unconsciously pricing in all the extra scope they’re no longer fighting. Neither side noticed that the battle lines moved.

The friction to add features dropped significantly, so the scope quietly expanded to fill the available time.

Let’s say we’re building that appointment scheduler, and we say it’ll take three weeks. At the end of three weeks:

Pre-vibe world: The system works, but just. It has exactly the features that match the most pressing business needs. Recurring appointments? De-scoped. Appointment reminders? Coming in v2. Mobile version? Soon. The PM feels satisfied: “Cool. Got the scheduler done.”

Post-vibe world: We have notifications. We have reminders. We have mobile. We have recurring appointments. We even added a little intelligence that notices when you’re making a similar appointment and helpfully pre-fills fields. The PM feels... basically the same: “Cool. Got the scheduler done.”

We forgot to even notice the 15 nice-to-haves that wouldn’t have been in this sprint three years ago!

The product manager asks, “Why aren’t we coding faster?” and we feel defensive because we are coding faster. We’re just also coding more.

Evidence that supports the intuition

I know this feels like anecdata, but the numbers back it up:

Most features don’t get used. Pendo analyzed real product usage and found around 80% of features are rarely or never used representing billions of dollars of build time diverted from actual value. Earlier Standish data put it at roughly 66%.

Scope creep is common and costly. PMI reported that 52% of projects experienced scope creep, and that that figure is on the rise.

AI does speed up coding… A 2025 study showed Google engineers completed an enterprise-grade task in 96 minutes with AI assistance, compared to 114 minutes without it, a 21% speed-up.

...but coding is the small slice. Atlassian’s 2025 DevEx report found that while devs save hours with AI, they lose similar time to organizational drag: finding info, unclear direction, cross-team friction. Coding is only about 16% of the week; the rest is everything around it.

And AI is not a universal accelerator. A 2025 study found experienced developers working in familiar codebases sometimes slowed down about 19% with AI assistants due to review and correction overhead. Useful, but not magic.

So, for most developers in most situations, yes, AI makes writing code faster. But the combination of (1) quietly enlarged scope and (2) all the non-coding work (discovery, decisions, reviews, integrations, QA, release, change management) eats those gains.

And even though, Atlassian’s report doesn’t mention my theory of increased scope, it’s a reasonable explanation for why so much time these days goes into engineering overhead. It’s always been the case that developers need to get requirements from PM, talk to other developers to ask questions about interfaces or how things work, do code reviews, and so much more. If the actual coding part of this cycle shrinks, then the frequency of all those other things will increase.

What to do instead of “just go faster”

Reduce sprint length. Sprint cadence should be carefully calibrated to the balance between distrating engineers and making sure they don’t veer too far off course. I used to like a one week cadence. In an AI accelerated world, it may be worth integrating everyone’s work and prioritizing the backlog twice a week.

Track the yes’s. Make scope visible. Keep a short list of “nice-to-haves” and ask weekly: which of these leads to revenue, retention, or learning now?

Produce according to demand. Align what you build to what customers will actually use or what will land more customers. Kill or delay the rest. It’s hard as a manager to be ok with developers waiting with nothing new to code for a couple of days, but it’s far worse for them to build unused features that don’t produce value and will later work against the organization by slowing velocity and adding maintenance overhead.

Protect the thin slice. Coding got faster; everything else didn’t. Invest in crisp requirements, slim approvals, paved-road CI/CD, and fast integration test suites so the non-code time doesn’t cancel AI’s gains. I like DORA metrics as a way to measure and encourage this.

Measure product, not output. Reward teams for adoption, retention, and sales impact, not story points or PR counts, which vibe coding can inflate without adding value.

Bottom line

I’m not saying don’t make beautiful, intuitive software where people notice the care and thought that went into the user experience. I’m saying not every idea is worth coding right now.

Vibe coding lowered the friction to say yes. Our discipline has to rise with it.

If we start noticing what we’re adding, and align scope to real demand, the org will finally feel the speedup AI already delivered.

Thanks for reading! Let me know if you have experienced this yourself or if you disagree in some way.
—Jon Christensen

But, I have found a way to make them great!

Instead of trying to describe what you like or give examples of what you like, you have to turn things around. “Tell me what I like. Explain to me why.”

But it’s even more subtle than that. You have to get ChatGPT to figure out why there are certain things that, by all accounts, you should like, but you don’t.

That’s where the magic is.

So here’s what I did. I said, “ChatGPT, here is a list of movies, books, and TV shows I loved. If every piece of media I digested could somehow be like these, I’d be happy. But I can’t tell what it is about these that I like. I want your help to figure this out. Here is another list of Books, TV shows, and movies that friends and recommendation algorithms thought I would like, but I ended up not liking them.”

So you tell ChatGPT those lists, and then you ask it to help you understand the differences between the things you like and the things you should have liked but didn’t. It will make you a table of what is present in the hits that is missing from the misses.

THEN you can say, “OK based on what you just learned about me, give me some recommendations for 5 books, 5 TV shows, and 5 movies that I will love.”

It will, but the problem is that you will have probably already read or watched most of the things in its first round of recommendations. It’s important that you react to these first recommendations with more feedback. If it works for you like it did for me, then almost all of its recommendations will be for things you already loved. Tell it whether it succeeded or failed, and if there are any recommendations it gives you that you didn’t like, ask it again to figure out why and update what it knows about your taste. Then keep asking for recommendations 5 at a time until you get some new ones that you haven’t read or watched.

You’ll be amazed. I have an ongoing conversation with ChatGPT where I’ve done this, and I have yet to be let down.

Give it a shot!

Share

—Jon Christensen

ps. no call to action on this one. I just wanted to share so that you waste less of your life on boring shows.

Here's a better framework: calculate the opportunity cost multiplier for strategic roles. If, by way of a round numbered example, you have a $10M business with 10 employees, each employee is generating roughly $1M in value annually—that's about $500 per hour of value creation, not just their $100/hour loaded cost.

When your top performer spends an hour on administrative work instead of strategy, you're not just destroying $500 in potential value. You're likely destroying much more. Strategic work requires sustained focus and mental energy. Once someone drops into grunt work mode, they burn through their daily capacity for higher level work, whether that work is social or requires deep thought. One hour of invoicing might kill their ability to do strategic work for the rest of the day—or tempt them into other low-value, high-dopamine tasks.

The kicker? Grunt work gravitates upward. Strategic people become the last line of defense when processes break down or need judgment calls. They're the ones who end up handling the "quick fixes" and "one-off exceptions" that junior team members can't resolve. This makes targeting their administrative burden the highest-ROI automation opportunity in your business.

My proof point: client invoicing used to land on my desk every month. Maybe 90 minutes total—not huge by loaded cost math, so I kept pushing automation down the priority list. Classic founder trap: "I can bang this out faster than explaining it to someone else." But invoicing had rolled up to me precisely because it required handling all our billing exceptions and client-specific arrangements.

We finally built the system anyway. Now it automatically nags for unlogged time, cross-references timesheets against workdays and PTO, and generates client-specific invoices with all our billing exceptions baked in. Month opens, invoices are ready.

What surprised me wasn't just getting time back—it was the headspace. Clearing that monthly context switch freed up mental energy I didn't realize I was burning. The relief gave me bandwidth to think strategically. This post might not exist otherwise.

When evaluating AI projects, stop asking "How many hours do we save?" Start asking "Whose hours are these, and what ripple effect does this grunt work have on their strategic capacity?" The real cost might be 2x, 3x, or even 4x the face value of those hours.

That's where the real ROI lives.

—Jon Christnsen

We’ve automated:

1. Invoice creation and time tracking for ourselves.

2. HIPAA-compliant email attachment processing for a health care client.

3. AI-SEO discoverability for a travel industry client.

We’ve noticed:

1. Our clients keep asking to put their own developers on our teams hoping that our skills will rub off on them.

2. Top AI companies like Open AI and DataBricks are charging wild rates for forward deployed AI engineers, and then quietly calling us and asking if we’d be willing to subcontract for them.

Transformation is a team sport

Well, the thing about pilots is that they don’t succeed when you send a solo smart developer out into an enterprise and say “go.” They succeed when you get a whole team aligned on a vision and work together.

Teamwork has always been our secret weapon, so we’re offering forward deployed engineering teams with a goal of AI-enablement for your team.

Our offer

At $50,000/month per forward deployed team, we’ve priced this well below what the BigCos are asking, but also in such a way that we are compensated for the valuable assets we’ll be creating at your company.

Our process

Pick a team

Part of this process will be applying our tech, business, and soft skill standards to your team so that we can make sure we have a group of people capable of leading the charge. You can read more about how we evaluate soft skills here (tldr; teamwork, follow-through, communication, learning, and flexible mindset):

Plan together, implement, iterate

With that team selected, we’ll do some planning together to choose the highest ROI thing that we can build and deploy effectively in your organization. That project will then act as the template for which your team will take over and run the next project.

Level up

Along the way, we’ll also teach your team about

• identifying automatable processes

• effective architectures for AI automation, and

• tricks for dealing with LLMs that like to misbehave.

This is the basic outline. The real plan will be customized to your company’s needs.

Learn more

We have a landing page for the new service here: https://aienablement.kelsus.com

If you want your AI projects to land in the five percent that succeed, let’s talk.

Schedule a Meeting

As a services company, we’re obviously willing to structure this in the way that will make it most effective for you.

Thanks for reading,

—Jon Christensen

Every time the economy goes bear shaped, leaders face the same hard choices: where to cut, where to hold, and where to actually increase investment. I've watched this cycle repeatedly—but this time around, something fascinating is happening.

Tech forward CEOs aren't just tightening belts across the board; they're strategically investing in AI-powered finance solutions. Why? Because they've recognized a critical recession strategy: automating back-office financial operations frees up capital to fuel growth engines that actually pull companies through downturns.

The Strategic Advantage Smart Companies Are Seizing

During downturns, most businesses instinctively retreat. They cut across all departments equally, including both operational expenses and growth investments. But companies that thrive through downturns take a more surgical approach:

1. Reallocate, don't just reduce – By investing in AI-powered finance automation, companies can dramatically lower the cost of essential but non-differentiating back-office functions. Those savings can be strategically redirected to customer acquisition and strengthening distribution channels.

2. Turn finance from cost center to strategic asset – Modern AI solutions don't just cut costs; they transform financial operations into a source of competitive intelligence. I was reminded of Nathan Baschez's excellent article "Execution is Exponential" when thinking about this. He describes how small improvements at each step of a process can compound into massive differences in outcomes. The same principle applies here – when finance teams get better cash forecasting, faster financial close processes, and improved decision support, the compounding effect on the business is exponentially greater than the sum of those individual improvements.

3. Deploy talent strategically – Instead of watching smart people leave because they’re tired of being Team Lead of Double Checking Data Entry, automation allows employees to focus on high-impact analysis and strategic activities. This isn't about reducing headcount – it's about elevating your organization’s work.

Why this Automation Wave is Different

Previous downturns brought rigid, rule-based systems—heaps of never-quite-working Excel macros and database procedures that fell over in a light breeze. Today's AI-powered solutions offer something fundamentally different.

It's the difference between navigating with a road atlas versus GPS. Both can get you to your destination, but one will have you waiting in traffic while the other can put you on a faster route and help you avoid a speeding ticket. These new finance systems AI solutions provide:

• Strategic agility – Quickly redeploy resources as market conditions change.

• Competitive intelligence – Reveal hidden patterns in financial data swiftly.

• Faster decision cycles – Minimize lag between financial events and leadership awareness.

• Operational resilience – Reduce dependency on specialized knowledge vulnerable to layoffs.

Where Leaders Are Focusing Their Investments

Having built finance solutions across a wide range of companies, I've observed these strategic priorities:

Cash Flow Intelligence – Beyond basic forecasting, these systems answer specific, high-value questions like "How will hiring Kelsus impact our cash flows?” or “At what point will this investment start to pay off?”

Resource Optimization – Companies are using AI to identify which customers, products, and processes are truly profitable versus those that just take up organizational cognitive load. Surprisingly, many supposed "key accounts" prove unprofitable upon deeper analysis.

Accelerated Financial Closing – By automating reconciliations and preparation tasks, monthly books can now be closed in days rather than weeks, giving leadership teams faster access to the financial insights needed to navigate uncertain markets. We once worked with a client that had paid millions for canceled subscriptions because their manual reconciliation process missed the details in vendor invoices—a costly oversight that automated reconciliation would have caught immediately and prevented entirely.

Decision Support Augmentation – Advanced systems proactively highlight anomalies, suggest optimizations, and quantify risks and rewards. It's like having analysts available 24/7 without additional overhead.

Why This Matters Now

In economic uncertainty, companies face competing priorities: cut costs while improving visibility and planning capabilities. Traditional approaches force painful tradeoffs, but AI-powered finance solutions offer a smarter path.

The strategic advantage is clear: by automating back-office financial operations, you free up capital to fuel growth engines – finding new customers and strengthening distribution channels. This resource reallocation often separates companies that merely survive downturns from those that emerge stronger.

At Kelsus, we've seen this firsthand. For example, we've automated nearly 40% of contract evaluations against invoices for a PE-owned client with $2 billion in revenue. Elsewhere, we're working towards automating every step of a complex business process for financing personal injury cases.

So while broader tech spending may be under pressure, don't be surprised to see continued investment in AI-powered finance solutions. Then when this cloud passes, and sales and marketing engines light back up, the companies that put in the work on the back end are going to emerge indomitable.

What is your company doing to brace for the storm?

Thanks for reading.
—Jon Christensen

Like many shoppers, I eventually opened a new tab and started searching "Best blender reddit"—not because Vitamix doesn't have great products (they do!), but because I couldn't quickly find the answers I needed. This is a story that plays out thousands of times a day across e-commerce. Eager buyers with credit cards in hand, getting lost in product catalogs.

I used to think that I didn't want to chat with websites and that sales bots were a bad idea, but I've changed my mind. I'd rather talk to a bot that understands the product lines and can answer my specific questions than spend an hour piecing together information from various review sites and forums.

This is especially true for products with important compatibility or configuration option—like when I recently bought a widespread faucet from Home Depot. Only after installation did I discover there were crucial mounting differences between widespread and center set faucets. A 30-second conversation could have saved hours of frustration and a return shipping label.

So wouldn't it be nice if there was a bot that could help you:

• Navigate to the products that match what you're looking for

• Point out things that are incompatible

• Help you with configuration options

• Answer questions about your specific use case?

Here's another real example from my life: I recently went shopping for a GPS e-collar for my puppy. I had a specific set of needs: it had to fit a small, brittany spaniel neck, work with my phone, and—crucially—function outside of cell coverage. What should have been a simple purchase turned into a multi-day research project. Even on major pet sites, finding these specific details meant opening dozens of tabs and still not being entirely sure I had the right information. What could have been a quick conversation about my needs turned into hours of frustrated searching.

To help you see what I mean, we've mocked up a couple examples. Here's a video showing how it might work on Etsy:

We also love showing how this works for products that need significant configuration. Here's a view of what it could look like on PCPartPicker:

But this isn't just a cool demo, we've integrated this into two real sites (while I can't name them publicly yet, I'd be happy to show you one in action during a meeting).

Not just an LLM—an Agent

What makes Klicker special is our state-of-the-art AI agent. The way it handles both complex configuration rules AND site navigation during natural conversations is something unique in the market.

But there's more: Klicker isn't just reactive—it's goal-driven. Need to build a complete PC configuration? Create a holiday shopping list for your whole family? Fill out a detailed user profile? Klicker will guide the conversation, asking the right questions and keeping track of progress until everything is complete. It's like having a skilled personal shopper who remembers exactly what you need and won't let anything slip through the cracks.

Even better, Klicker has an uncanny ability to understand human taste and preferences. Just like a great salesperson who picks up on your style from casual conversation, Klicker learns what you like through natural dialogue. Whether it's your color preferences, style choices, or specific requirements, Klicker remembers these details for returning visitors. And yes, we can integrate these valuable insights with your CRM, turning casual conversations into actionable customer data.

Klicker enables real buyers to get real answers and make confident purchases, often completing complex shopping tasks they might have abandoned otherwise.

Please help me get the word out about this. And if you work with any e-commerce or travel businesses, I'd love to talk.

Engagement Models

We believe in flexibility when it comes to deployment. Whether you prefer self-hosting or our managed service (SaaS), we'll work with you to ensure a smooth integration. We can either lead the integration or partner with your technical team.

We offer two engagement paths:

• Standard Integration (4-6 weeks): Ideal for smaller sites with straightforward product catalogs

• Enterprise Integration (up to 6 months): For larger sites with complex product relationships and custom requirements

In both cases, we work closely with your team to ensure Klicker understands your products, configuration rules, and customer needs.

Schedule a call

Thanks for reading!

—Jon Christensen

ps. Klicker is the fulfillment of my lifelong favorite Seinfeld scene. In 1995, an episode of Seinfeld aired where Kramer pretended to be the voice of the Moviefone service— a phone number people used to call to find out when and where they could see movies in theaters (apparently it still exists?). I absolutely loved that scene and for 30 years, whenever a situation came up where my employers or clients wanted software beyond what was feasible with state of the art technology, I've referenced that clip saying, "Why don't you just tell me the name of the movie you want to see?" This future has finally arrived.

SaaS thrived on the promise of scalability – distributing identical code to millions of businesses through the magic of the internet. But this model has a critical flaw: it can't perfectly solve any single business's unique problems. As code becomes cheaper to produce, the balance is tipping in favor of tailored solutions.

The power once held by SaaS giants stemmed from the mountains of code they'd written—a moat that's now eroding. Whether AI will churn out high-quality code next year or in a decade is debatable, but the trajectory is clear: we're sliding down the slope of ever-decreasing software costs.

This seismic shift opens up a world of possibilities for businesses of all sizes. Custom software, once the domain of tech giants and Fortune 500 companies, is becoming accessible to a broader range of organizations. Here's why this matters and how it's reshaping the business software landscape:

The Inherent Limitations of SaaS

When you target a large addressable market, you're not really solving any business problems perfectly for any of your customers. Sure, there might be some configurations you can do, but there's no place in the QuickBooks configuration to tell it, for example, that Tara said invoices must not exceed $50k per month, so Lynette should track any overage in a separate spreadsheet and add it back in some month when the invoice is less than $50k. Businesses are full of little rules like that. The bigger the business, the more there are, and SaaS sucks at dealing with them.

This fundamental limitation of SaaS is becoming increasingly apparent as businesses grow more complex and demand more tailored solutions. Forward-thinking companies are starting to look elsewhere.

SaaS is eating itself from the inside out

Meanwhile, it seems like SaaS companies know this. They’re sprinkling AI on their products like a 3 year old with a cake and jar full of jimmies. So far, these AI features don’t provide much business value. Since their connection to other systems is rigid and knowledge of data in other systems is tiny, there’s not much they can offer in terms of automation without having to write some custom code.

But if they don’t solve every problem, at least we can trust they’ll be here for the long haul? Not so fast. We didn’t always trust in SaaS. In the mid-2000s, IT managers had to be convinced that it was safe and secure and here to stay. Now, though, even Google is fighting for its life against OpenAI, Perplexity, and itself (Gemini). In addition to big threats from AI, there is never ending, market eroding, competition in SaaS. Vertical SaaS for tattoo shops, gyms, small grocery stores, large grocery stores, golf courses, everything are eating away at the addressable market for horizontal ERPs. There will be further and further verticalization of the various SaaS product markets in the coming years. When it becomes possible to have a viable business on a customer base of 10-15 companies, people will do it—they already do it!

Custom software is better for people

Businesses are a way of aligning groups of people from employees, to customers, to investors around a shared goal, and software is a critical component for scaling those organizations. Modern software has enabled organizations to effectively grow to millions of people. Walmart has over 2 million employees! But everyone who has ever worked for one of those organizations knows that huge companies are heinously inefficient. Forgetting to put the new cover sheets on your TPS reports can be soul crushing.

Small organizations that let humans work as people doing people things are way more efficient at making decisions, changing their minds, and getting work done. Part of the problem with big organizations is that even though they make good use of software to keep everyone marching to the same beat, the software forces people to behave in certain ways and it becomes the job of many people within the organization to make sure that people are conforming to the communications and process policies and constraints created by the sheer size of the organization and the software it uses.

This is where custom software shines. While it may require more upfront investment in time and resources, it allows organizations to build systems that work with their unique processes, not against them. Instead of forcing people to adapt to rigid SaaS solutions, custom software can be designed to enhance existing workflows, potentially reducing long-term costs associated with workarounds, integrations, and unused features.

If a 100,000-person organization could somehow be a highly orchestrated hive of 5000 twenty-person organizations, with each of those smaller organizations using the effective processes and human communication afforded at such small scales, we could do away with huge swaths of management and mind numbing software. Custom software could be the key to achieving this level of flexibility and efficiency, adapting as quickly as the business itself evolves.

Embracing the Custom Software Revolution

I think this is the promise of custom software. I can imagine a world where spreadsheets are ok, but automated, where the integrations and inputs and outputs across teams can be put into code almost as easily as you can think it. But in the meantime, it’s time to start planning for that future. At the very least, I suggest if your team is evaluating RAG solutions or trying to figure out how to ‘use this AI stuff’ to do something useful that you don’t go looking for a SaaS product to help you do it. Build it yourselves. Own it, and improve it. Take a ride down the slide of the ever-decreasing costs of software and land in the future.

—Jon Christensen

ps. Kelsus would happily do a free evaluation of your business or organizational unit to see where custom software makes sense. Reply to this email, and I’ll set something up.

As a mentor for several incubators, I’ve had a front-row seat to the entrepreneurial reaction to GPT. And I’m so glad I’m not running a startup that just raised VC money on the promise of some solution delivered on the GPT platform. During this week’s keynote, Open AI basically drained all the moats—or at least showed they have no intention to help anyone maintain any kind of technology moat.

Here in Startup Win! recently, I’ve written a lot about how the key thing that AI unlocks is completely customized software that does exactly what your business needs it to do. Meanwhile, incumbent SaaS providers like Salesforce or QuickBooks always prioritize whatever will sell the most seats of their product which may not align with your business’s specific needs.

It used to be that writing custom software for all of your business’s specific needs was grossly too expensive. SaaS companies spread the software development and maintenance cost across a ton of customers, and survive off this economy of scale. AI drops the price of one-off software solutions to a point that it becomes worth it to automate things that used to be more affordable with inexpensive manual labor. And yet there are a bunch of entrepreneurs running around trying to use the same SaaS playbook. It’s the wrong move.

The right move is to start saying yes to software perfectly customized to your business operations and build it for yourselves. We’ve already seen this to be true here at Kelsus. Over the years, I’ve been approached by developers that wanted to automate some aspect of HR (like timesheets) or client management, and I’ve always said no. I myself have wanted to automate certain aspects of invoicing, payroll, or onboarding but I’ve always reminded myself that a few hours a month doing boring manual work is still cheaper than having some custom software that we need to maintain.

Well, now it’s worth it. We’ve been hard at work inside Kelsus automating all the things.

And now the pitch: We’d like to do this for your company.

We believe that it doesn’t come naturally for many developers to become efficient with GPT because it requires changes to how you plan and work that many developers are reluctant to make. Your internal IT team is already doing business as usual, and isn’t thinking in this new way.

We also believe that many managers and line operators just aren’t aware of the vast array of opportunity for automation within the business. Some areas to think about:

• Do you still rely on people to extract information from PDFs?

• Do you have to nag people to do some manual thing on a regular basis? (We recently wrote a Slackbot called WorstNightmare that nags people that haven’t done their timesheets, but it first checks the vacation calendar.)

• Do you rely on people to put information from another system into another?

• Do you have financial people that make sure your invoices “look about right”?

• Are there any analysts who are responsible for reading a bunch of stuff and keeping an eye out for something unusual or important? (We wrote a system called Kelsus Constellation that scrapes websites and intelligently filters the results looking for promising businesses to acquire.)

We have a million more ideas, but I said I’d keep it short.

We’d like to pair one of Kelsus’s product managers with direct support from me and a team of two Kelsus developers to start automating the living hell out of every operational process at your business. They’ll be responsible for not just building new automation tools but also for maintaining all the ones they’ve already built. And over time, again because AI is so damn good these days, they’ll organize the systems they build into a clean, clear, extensible architecture rather than a nasty mess of stray cats cluttering up your AWS accounts and angering your IT and security teams.

This is a call to anyone with enough authority at a business to see the value this could provide, and allow us to work outside of the cadence of your regular IT and product development team.

One more thing I’ll throw out there. If you want one or two of your own team members to join us, we’ll be happy to have them along so long as we use our experience and knowledge to drive the process. Another consultant friend refers to this as “happy to have them join so long as they understand they're coming to our party.” The benefit of this, would be of course for these developers to pick up some of our techniques for producing highly customized software at alarmingly fast rates.

Thanks for reading, and I know this is too short to have answered all your questions, so please get in touch and I’ll answer the rest (not via a bot).

Replying to this email is the easiest way to get in touch.

—Jon Christensen

P.S. You might wonder about our view on the balance between automation and oversight. Here’s how we think about this. Anywhere something is automated (especially with GPT), it should be treated as though a person is doing that thing. And as with anything that any person (no matter how conscientious) does mistakes are possible. So, if mistakes are irreversible and costly, then work should be double-checked by other people.

So we think when automating things, if mistakes are not that big a deal, let them be fully automated; if mistakes are expensive, then make sure that real humans are in the loop—even if all they have to do is double check GPT’s work or monitor an errors queue.

Clayton Christensen wrote a book called The Innovator's Dilemma in which he observed a pattern of innovation. The pattern goes like this: new innovations start as a vertically integrated system (think of the first car or the first PC) and then get “unbundled,” as new companies form to create modular improvements (think about windshield wiper motor specialty companies in the car world or hard drive makers in the PC world).

Ok, so in the article I read this morning, Benedict is looking at this new, vertically integrated product ChatGPT (or just GPT in general), and thinking about how it’s going to be unbundled. And, his thesis is that the various things that an LLM can do (from giving medical advice, to helping make travel plans) are going to become the next wave of software businesses.

WRONG.

This is not the future despite so many people trying to fund it and build it.

Recently, I went to a Fintech Conference in Copenhagen, and brand new companies were off to the races building niche GPT-powered solutions for well defined markets that they believed had huge growth potential. Likewise, I went to a mentoring session for a new batch of Techstars companies, and at least 4 of the 12 were aiming to harness LLMs for some niche.

Many people have expressed that the problem with this is that there’s no moat. Yes, some other company could come along and easily copy your wrapper around the GPT-4 API that helps teachers create engaging lesson plans, but worrying about moats is missing the entire point.

Because I want to keep you reading, I’m going to hold off just a second longer in telling you the entire point.

Instead I’ll tell you something that helped me realize what the point was. So my company, Kelsus, is starting to look at acquiring companies. We are interested in acquiring well run, vertical SaaS companies that have over $1M in revenue, and fit a specific thesis.

Ok, so here we were wanting to find these kinds of companies for sale. Have you ever looked at buying a company? You have to wade through thousands of garbage listings of horrible companies that should just shut down. And then beyond that, it’s hard to compare one company to another based on numbers like their asking price, revenue, EBIDTA, etc. So I started building a tool.

Using ChatGPT to help me, I built a tool that could

1. Scrape websites full of company listings and drop their information (URL, description, asking price, revenue, profit, location, etc) into a Google Sheet.

2. Hand the content of that spreadsheet off to GPT-4, so that it could read the description of the companies and score each one on our thesis on a scale from zero to one with one being “definitely matches the thesis.”

3. Lastly, it would take the contents of that spreadsheet, build a weighted scoring model, and plot them in a chart so that the most interesting acquisition opportunities would end up at the top of the chart.

I built this tool in under 40 hours of development. It is fast and loose, a bit brittle, but it does the job. I stopped working on it when marginal improvements to the software weren’t saving me time at finding target companies.

After I built it, you better believe that I thought about marketing it as a product. My entrepreneurial streak runs deep.

But I knew better. What made the tool valuable to me is not that it could scrape business listings and score them. Its real value lay in its perfect alignment with my specific needs and expectations.

And there it is. THAT’s what the problem with companies trying to build LLM-based tools for niche markets is. You’re trying to build a product for a broad set of users but the power of AI is that it you can build a product for yourself (or your specific business).

I think that we’re so used to living in a world where products are not 100% customized to ourselves that we have a hard time grokking this transition. But as soon as you think about it it’s obvious. What if the bicycle you bought was built exactly to your fitness level, body geometry, and riding style. It would be amazing! What if you never missed a UPS delivery because they just knew better than to deliver when you weren’t home? Perfect world, right?

So now we need to extend this to how we think about software. This new market reality is not about improving undifferentiated products through bundling and unbundling. This is about converting a singular B2B product serving 100,000 customers into 100,000 unique B2B products, each serving a single customer.

So, when Benedict Evans, or Ben Thompson, or really any market analyst Bens try to look into our AI-assisted future and understand what the big new companies will be, they should be looking for companies that accelerate this journey from 1 to 100,000 products. Those are the ones that are going to be giant.

In a final note to tie together my thoughts on where AI is going and what Kelsus is doing in terms of finding acquisition targets. For the moment, Kelsus is still completely involved in providing software services. But we see the value of billing for software development by the hour going down fairly quickly already as LLMs help with the heavy lifting, and we’re concerned about the commodification of development skills.

So, rather than be the software developers, we’d rather be the software providers, and that’s why we’re looking at doing acquisitions. But as a bonus to this way of thinking, we believe we can take advantage of the development speed that LLMs unlock and start driving hitherto unaffordable, individually customized products to the customers of the vertical SaaS companies that we acquire by leveraging the power of LLMs.

This is going to take us a long time to put together, and in the meantime, we’re very much still open for business as a custom software development shop, but if there are some things that you wish your software could do that have felt too expensive or time consuming or not worth the investment, maybe give us a call. This is a new world where massive software value can be unlocked in incredibly short amounts of time.

Thanks for reading!

—Jon Christensen

These shouts of frustration were rarely met with responses, or if they were, it might be a sardonic, “Go home, Kurt. The machines won today.”

If you’ve worked in an office at a software company, this probably sounds familiar, and if you’ve transitioned to the remote workforce, there may be some small part of you that misses it. For developers, shouting our frustrations can be therapeutic, a way to release the built-up tension of hours of debugging or being stuck on a challenging problem. It's the coder's version of screaming into a pillow. And while it might startle a newcomer, those well-acquainted with the world of software development often see it as an endearing quirk, a shared experience that bonds us in the sometimes-solitary journey of coding.

When you’re working remotely, it’s just not quite as satisfying to shout to an empty room. And as much as some people have tried to use Twitter for this, it’s a bit too weird, especially now with Elon reading everyone’s tweets.

At Kelsus, we use Slack as our virtual office, and in an attempt to resurrect the ritual of coders shouting out their pain, I made a channel called #yelling where anyone in the company could type something that was making their day difficult.

Here is a typical entry from #yelling.

When people posted in yelling, they got the sense that other people could see their pain and participate in the collective experience of software developer agony, but as you can see, the responses were pretty sparse. No one is telling Jenks to give up and go home, not for the least reason that he is already at home.

So recently I decided to try to spice up the channel by adding a bot. I had specific outcomes I wanted for the bot. Firstly, I wanted it to reinforce that our collective suffering as developers that spend our days in our head fighting against obstinate computers doesn’t need to be borne alone. Secondly, I wanted to emphasize that we started building software because it’s fun, and making stuff for computers can still be fun, and finally, I wanted to lead by example. Maybe as the CEO of Kelsus I should be making sales calls or advising clients, but sometimes I still like to spend a few hours behind a screen of code.

The result of my quest was Gritobot, a sarcastic, nihlistic football fan that pokes fun at our struggles inside the #yelling channel. I used ChatGPT quite a bit to help me build the system and teach me AWS SAM, so that I could easily deploy it to our company AWS account. (I’ve added a link to a public repository with Gritobot’s code at the end of this post if you’d like to play with it yourself).

Building the bot ended up being like working with a partner with ChatGPT helping plan and debug the entire application. Here is ChatGPT’s very first response to my request for help building the bot:

At the end of that excerpt, it says “When you’re ready…” That’s because I prompted it to go in steps with, “You can give the instructions to me in pieces and parts and after each part I'll tell you when I'm ready for the next.”

And I didn’t build the whole bot in a single conversation with ChatGPT. At one point, I was fed up with uploading zip files to the AWS Console to update my bot whenever I made code changes, so I decided I wanted to use an AWS tool called SAM to make it easier for me to make updates. When I decided to do this, I started a new conversation with ChatGPT like this:

And once again, ChatGPT was able to walk me through the process with relative ease. Something important I do is that I ask ChatGPT to explain things to me that I don’t understand instead of bumbling forward in ignorance.

Once I had Gritobot working, it was a little too stupid and a little too mean.

To make it smarter, I had to solve a problem. The problem being that I was only sending the GPT API the single message that the user had written, and none of the conversation history in the channel. So in the messages above, Gritobot only got “I coded up @Gritobot myself…” and “What’s my name, @Gritobot.” It’s difficult for a bot to sound smart in a conversation if it only knows the last thing that was said and not what the conversation has been about. So, I updated my bot back end to request the last 15 messages from the #yelling channel to send to the GPT API.

The other thing I needed to do was a Slack-specific issue. In Slack you can converse in the main channel or in a thread, so I needed Gritobot to be able to get conversational context from either place. Here’s an example of me proving to myself that Gritobot could follow a conversation into a thread after I had made a few updates (again with ChatGPT’s help).

And, finally, I had to try to make it a little less heartless. When my first couple of tries to soften the bot’s demeanor by updating its initial prompt didn’t work, I asked ChatGPT for help and got a good suggestion:

The final result is a sarcastic but playful friend who sometimes tells us to go home and other times helps us remember that we’re all on the same team. We also love knowing we have this bot template to use for any other thing we might want in our Slack instance.

Now, I’ll share the URL to the public repository. I’m happy to accept PRs if there are improvements you think should be made, and I’ll also accept criticism that is sent with heart, but if you want to just tell me that my code sucks, you can just go shout it into the void.

Visit Gritobot’s public repository on Github!

https://github.com/Kelsus/gritobot

I’m curious if anyone reading has a similar bot or channel? Or even better if you’ve found a way to replicate some other niche element of the developer experience that used to be limited to in-person work?

Thanks for reading!

—Jon Christensen

I walk around with a few things kicking around in my brain at all times. Every once in a while, those things come together in a way that feels additive, like a flash of insight.

Yesterday I was walking around in these 1st century B.C. Celtic ruins in Spain imagining the lives of the 3,000 people that used to live here when I had one of these moments.

The people who lived here likely had to put quite a bit of energy into securing their food supply and staying safe from other people. After all, they built their village on top of a mountain with 360 degree views, when it would be a lot more convenient not to have to live at the top of a mountain.

Porto and the Industrial Revolution

Of course, thinking about how people spend their time got me thinking, as I do every day these days, about AI and what will happen if we don’t need smart people to think hard about things they’d rather not think about. If we don’t need as many lawyers’ brains to think about boring contracts, and we don’t need as many software developers’ brains to write enterprise integrations, what happens?

Just 120 kilometers south of these Celtic ruins lies the next step in yesterday’s chain of reasoning. The city of Porto is a topographic wonder—a sparkling city built into a canyon with enough ornate tile to have kept hundreds of master tile workers busy their whole lives for generations.

The reason that Porto has so much tile is directly attributable to the Industrial Revolution.

1. Technological advancements: Improvements in kiln technology and the development of new techniques for producing and decorating tiles made it easier and more cost-effective to create high-quality azulejo tiles.

2. Urbanization: The Industrial Revolution led to a significant growth in cities and urban areas. As Porto expanded and new buildings were constructed, there was a greater demand for decorative tiles to adorn the facades of buildings, churches, and public spaces.

3. Accessibility and affordability: Mass production of tiles during the Industrial Revolution made them more affordable, which allowed for their widespread use in architectural design.

4. Cultural significance: The azulejo tiles became a symbol of Portuguese culture and identity, and their use in architecture and public spaces increased as a result.

I put cultural significance in bold because of how important it is. Tiling buildings doesn’t put food on the table unless people value them.

Our current locus of cultural significance

Here we are at the final piece of the moment of insight I felt looking out over the waters of the Atlantic. What will we (collectively) value so much, that when we have the time, we can pour all of our energy and effort into it? What is the AI Revolution equivalent of Porto’s azulejo tile?

To get there, I’ll start by remembering my childhood. I started learning how to program in 4th grade with my dad’s Apple IIe. Of course, I wanted to learn how to make games. Fortunately for me, it was possible to code up (or copy code from a book) some simple games in a few hours of effort. I could make little choose-your-own-adventure text games and show them to my friends at school.

Since then, games have become a lot more complex. AAA games these days can involve massive teams that include thousands of people from game designers, programmers, artists, animators, and writers to voice actors, sound designers, and more middle managers than even the most ambitious sky scraper project.

So the other day, I was watching my seven year old playing with Bloxels—a graphical coding app for kids—and creating more sophisticated games on his own than I could when I was starting out. I noticed that some of the games he had made had a counter on them of how many times they had been played.

“Wow I said, people have played this game 2000 times?”

He flipped through some screens deftly, and said, “That’s not my most popular game, this one is.” The number in the corner of the thumbnail was over 20,000.

As soon as he has AI tools to help create assets and environments based on his simple descriptions of what he wants, he’ll be able to create really sophisticated games by himself.

But all those people that enjoyed collaborating on those giant AAA games will still want to do so—albeit not by doing some of the things they previously had to do like managing asset pipelines or manually building shaders.

This media entertainment, this creation of worlds for us to passively watch (Game of Thrones anyone?), or games for us to explore in groups or by ourselves (Final Fantasy XIV and God of War as examples), already have global cultural significance.

And sure, extrapolating this causes me to have visions of everyone plugged into the matrix, or living in the hellscape imagined in Ready Player One, and I’m not sure I’m entirely excited by a future that’s more about building simulations than beautiful cities. To be very clear, we really need to make sure that people continue to have a choice in how they participate in the future, and just as Porto is a shining example of what we can build when we have free time, Detroit is an equally important counterexample of what happens when we no longer need certain labor.

But I do love a good show.

Just as not everyone in Porto was an azulero in the 19th century, so too, not everyone will be a movie maker or game designer during the AI Revolution. For the people that do opt in, I like to imagine a future where they collaborate to build ever more nuanced and immersive digital experiences.

To me, this is much more compelling and likely than the alternative I’ve seen postulated where the AI just creates an endless personalized show/game/book for each person. Especially because, as we saw already with my seven year old with his pride on the success of his game, our desire for status is innate and won’t be quenched by AI generated entertainment.

It’s thrilling how fast this is all happening and I’ve loved watching how it plays out. I’m glad that we already have so many books and movies like Ready Player One and The Matrix that are part of our collective cultural fabric because even without having any kind of ability to govern and set policy ahead of the changes that this technology is causing, we already have a shared understanding of some of our possible futures and the futures we don’t want.

—Jon Christensen

Before I tell you the idea, let’s first agree that we’ve seen a convergence of people believing that the big thing that’s about to happen is a reduction in cost of software development to zero. Because this is my newsletter, I’ll personally take credit for that idea since I wrote about it on December 8th 2022, and the more viral piece that said essentially the same thing came on March 31st by Paul Kedrosky. What I said was, “Now, huge backlogs of customer ideas and one-off requests squirreled away in product management tools will become viable,” and Kedrosky put that much more succinctly as “society’s technical debt.”

Of course, talk like this causes software developers everywhere to wring their hands and worry about their futures. We wonder whether it still even makes sense to learn to code.

I’d argue that it does, but it does in the same way that it made sense for me to learn assembly language even though I’ve never had to use it professionally. It helped me develop a highly detailed and complete model of how computers work that has been relatively easy to keep up to date as technology has improved over the past 30 years. The value of having a complete mental model doesn’t go away until we arrive at superintelligence at which point all bets are off, but this post isn’t about superintelligence.

So remember I said I was going to introduce one new idea? Here it is:

Rather than making software development easy for anyone, we are going to see an EXPLOSION in the complexity of the systems. It will become ever more difficult for new people to learn everything they need to know to build their mental models, and more difficult for us all to keep everything orchestrated and working.

Why? Because THAT’S WHAT WE DO!

Here are three reasons you should believe me:

1) We tried simplicity and said no thanks. There was a brief period of convergence around 2006 where Ruby on Rails was invented and it made building the types of websites we’d been building over the prior few years vastly easier. That time period was an oddity, and while it did spawn a couple important companies (Github, Twitter), we quickly moved on to adding more and more complexity to our websites. We decided to make them more distributed so as to have low latency from around the globe, have higher expectations of uptime, handle orders of magnitude more data, and increasing complexity and interactivity on mobile front ends. We also went from ‘git push origin heroku’ to AWS.

2) Complexity is developer catnip. AWS is worthy of being my second point. It’s not a coincidence that it is both the most successful public cloud with the most adoption by developers and the most complex. We love it. People take 3 hour certification exams for no good reason to prove how well they know it. AWS made a relatively user friendly way of orchestrating containers called ECS and developers were like, “Noooo, we’ll take Kubernetes thank you!” (Which if you don’t know much about kubernetes, it is a hydra monster with 58 million lines of code who’s job is ostensibly to run distributed systems across tons of computers but who’s actual purpose is to keep devops engineers entertained at work.)

3) Even when not building mission critical systems, people choose complexity. Here’s a data analysis from 2018 showing that board games have been getting more and more complex, and a subsequent graph showing that people prefer more complex games. We like complexity even when we’re supposedly relaxing. This is what we do!

Do you believe me now? ChatGPT and whatever other dark genML magic are not going to make all this complex and difficult software go away. I think a better way to think about it is to look at the way things already work. Already today, the most highly paid developers (principal level devs) are the ones that can imagine an entire complex system and then break it down, estimate the effort it will take to build it, and steward it into existence. Now they’ll be able to steward more complex systems into existence because the more junior people on their teams will each be able to produce their own relatively complex systems with the aid of genML. System level thinking with a complete mental model of how the software works will still be required of the more junior developers because that is how they will prove that they are ready to be promoted to a more senior role.

It’s fractal in nature. GenML gave us the ability to zoom in one level deeper into the fractal, and the patterns we can now see and build are vastly more articulated and complex.

This game is infinite.

—Jon Christensen

Lots of people jumped into the discussion to answer. One person said they are skeptical of contract work because contractors are mercenaries for whom the grass is always greener at another (higher paying) gig. Another person said that the culture of some organizations includes something called “not invented here syndrome” which means they like to build everything themselves even when open source or commercial options are available.

We were well into the discussion, when someone wrote the sagely worded, tempered, canonical answer to this question. The common wisdom is that it’s “best to hire in-house for your core competencies and for the extraneous stuff, maybe you can outsource.”

I’ve heard this idea for 20 years. I’ve said this to people. If this is true, it would mean that your startup MVP should be developed by founders or employees. If your company is not a startup, it would also mean that you shouldn’t hire contractors to work on core systems. I’ve accepted it is as part of the bedrock. But why? Is it really true?

To understand why this is the common lore, lets first break it down and look at the arguments in favor.

Don’t stop reading here! This post will take an unexpected turn.

Subscribe now

1. Greater control over the development process: When a company has its own employees working on its core competencies, it is able to dictate in fairly absolute terms how the work gets done, what computers are used, what hours are worked, where the work takes place, etc.

2. Improved communication and collaboration: When employees are in-house, it is often easier for them to communicate and collaborate with other team members. Managers can ensure that everyone is working towards the same goals and that the company is able to respond quickly to any challenges that may arise.

3. Increased flexibility: Having in-house employees who are responsible for core competencies can give a company more flexibility to adjust its resource allocation as needed. For example, if the company needs to ramp up development of a new product, it can easily reassign employees to work on that project.

4. Greater access to intellectual property: When a company has its own employees working on its core competencies, it has more control over the intellectual property that is generated. This can be especially important if the company is developing proprietary technology or if the core competencies are closely tied to the company's brand.

5. Enhanced security: In some cases, a company may have security concerns about sharing its core competencies with outside contractors. Having these employees in-house can help address these concerns and ensure that the company's critical information is kept secure.

This seems like a pretty solid list of reasons taken at face value. You can imagine a smart software manager with years of experience listing each one of them while counting them off on her fingers. And most people would be convinced.

Here’s where we take a sharp turn.

But let’s look at them again one at a time and figure out if there is anything substantive supporting them.

1. Greater control over the development process: I used to think that you can tell employees exactly how, when, and where to do their work and that you can’t do that to outsourced developers or firms. But this isn’t actually true. There’s no law that says you’re not allowed to control the manner and method of contractors’ work. There’s just a general tradition of not doing that.

   Before continuing I should give a quick nod to the fact that there’s a test called the “common law test” to determine whether workers should be classified as employees or contractors, and it includes the following factors to determine the level of control that a company has over the worker, including whether the company:

   1. Has the right to control how the work is done

   2. Provides training to the worker

   3. Requires the worker to follow specific procedures or processes

   4. Determines the order or sequence of the work

   This common law test is only one of the possible tests for making the employee or contractor determination, and it doesn’t really come into play when hiring an agency to do the work. It also wouldn’t come into play if a contractor specifically wants to be considered a contractor and has evidence (a contractor website, for example) that they prefer this type of working relationship.

   What I’m saying is that you can control the development process. Heck, you can even put specifics of how, when, and where the development should be done into a legally binding contract.

   I do think there’s one thing to consider that’s a little different between teams hired through a firm or agency and hiring individual contractors or employees. That is the ability to go into “hard core” mode as Elon Musk would say.

   Let’s say the business has decided that they need people to work 18 hour days 7 days a week, and they’re willing to take whatever risks that might entail to productivity and morale. If everyone has been individually hired (either as contractors or employees) then people who disagree with hard-core-mode might choose to resign. The manager might resign but leave the team to be managed by someone else, and a few of the individual team members might resign as well.

   However, if the team was hired from a firm as a unit, then the firm might refuse to go into hard-core-mode as a unit and look to exit the engagement entirely. Fortunately, this is probably not too much of a concern for most companies, because, as we have learned from Twitter, going into hard-core-mode is a horrible idea, and many people will leave (taking their institutional knowledge with them) no matter what their relationship to your company is.

   There’s one final little bit of nuance to consider on this development process point. If you’re hiring a team from a firm that has a long history of experience working together, then they’ll probably price their service in such a way as to bill for the value of that long experience. If you already have a development process at your company that is very effective at producing successful outcomes, and you want the outsourced team to use your proven process, the outsourced team will have to change from the way they are used to working to learn the new methods. You’ll be paying a premium price for that outsourced team because of the experience and development process they already use but won’t receive the benefit of it. For companies that already have a very effective development process, it’s probably better to hire individual contractors and in-house employees rather than an outsourced team.

2. Improved communication and collaboration: This is an easy one to refute. How do your employees already communicate with one another? Face-to-face in a building? On Slack channels and emails? What physical or process barriers does your company put in place that makes communicating with outside contractors or organizations different? I’m certain that all of those barriers are policies are not laws of government or physics. If you want to maximize your ability to work with an outsourced team, you just need to make it as easy for them to talk you your employees as it is for your employees to talk to each other. This doesn’t mean that you need to give a third party software development company access to the company directory. They just need to be able to easily communicate with people that are relevant to the project they’re working on.

   Communication barriers can just as easily be erected between in-house people. Your company’s Slack might have private channels for executives. There may be whole multi-billion dollar projects (VR at Apple?) that most employees don’t even know about.

   Bottom line, communication between outside developers and employees is only an issue if your company makes it an issue.

3. Increased flexibility: The idea—that you can move people around and have them work on different things as priorities change thus giving you more flexibility—seems true on the surface, but it isn’t actually true. The reason is that software developers aren’t fungible. I can’t think of many professions less easily replaceable than software developers other than, say, Hollywood actors in the middle of filming. Even a good surgeon could take over mid heart transplant for another, but software developers create a mental model of the code they’re working on that is very difficult and time consuming for another developer to come in and take over. There’s a significant cost involved in moving developers around. So, when you’re adding capacity to a project, it’s best if the you’re not taking that capacity away from another project. It doesn’t seem to matter whether the added capacity uses an employment relationship, and it’s probably easier and lower risk to add capacity through contractual relationships than with employee relationships. Removing capacity from a project is always difficult and may require difficult decisions about letting deep knowledge of the codebase go regardless of the type of working relationships you have with the developer.

4. Greater access to intellectual property: We’ve seen critical intellectual property leaked by employees—famously, the Gizmodo iPhone 4 leak of 2010, and in 2006, Coca-Cola faced a major leak of its secret formula when an employee shared a copy of the recipe with a journalist. So, trusting people with your company’s intellectual property does not boil down to the working relationship you have with them.

   Usually when talking about software development contractors and intellectual property, the thing that comes up is contractors bringing their own code—whether privately developed by the contracting company or open source—to a project. There’s a famous case involving the developers of a Unix toolkit called BusyBox suing a dozen companies that refused to publish their source code after including BusyBox in their product (publishing your source code is a requirement of the GPL license). Since that case, IP lawyers doing due diligence have been particularly nervous about developers using open source tools. That case really has nothing to do with whether the developers are contractors, but you can see how it would create a fog of intellectual property paranoia.

   Kelsus has its own story to refute that there are intellectual property issues that stem from using third party contractors. We built an entire product over the course of four years for a startup that, for contractual reasons, I cannot name. That product was purchased in an asset sale for an 8 figure sum. The revenue of the purchase went to company and ultimately its shareholders, while Kelsus was only paid for the development services rendered. The intellectual property transition was smooth, standing up to rigorous due diligence performed by a big five accounting firm.

   To summarize, your intellectual property and its safety have little to do with the technical working relationship you have with software developers, and more to do with having good working relationships with the people that build your products and careful legal review of the contracts you have in place with your in-house developers, contractors, and open source licensors.

5. Enhanced security: If you understand cybersecurity, you understand that information and networks don’t inherently behave differently depending on the employment status of people that have access to them. What I mean is that the bits flowing through the tubes are just bits. They don’t know who you really are—only who you’re logged in as. Your company may have added security policies to its systems to limit or enable access to certain systems based on the identity of the user accessing it, and it may have a database that segregates employees from contractors. If your company does have a different blanket security posture towards contractors than towards employees, then it’s probably more likely that a security problem will come the group whose blanket policy is less restrictive (the employees).

So that’s it! I’ve refuted five for five in the list of reasons that it’s better to not let outside vendors work on core competencies. The only concession I gave is that it’s better not to hire an experienced team as a unit and force them to change their method of development to match your preferred method of development because you’ll slow them down and waste one of the benefits you’re probably paying for.

We’re not quite done, though. Businesses are groups of people making decisions and they don’t run on absolute truths. I’ve made an argument that there is nothing inherently preventing outside developers from doing great work on core competencies for your business, but it could be worth looking at this from a different lens. If contractors generally are a poorer choice for working on core competencies because of the factors described above, then we should understand that and plan accordingly.

It turns out there’s some research on the matter. Professor Michael Steven of the University of Marburg did a study, published in Management Revue in 2010, on whether outsourcing in the prior 20 years had caused firms to lose their core competencies. His finding was that they had not, and that the knowledge boundaries of the firms had been decoupled from their production activities.

There’s also the matter of job security. This article in Harvard Business Review, suggests that historically, people felt they could rely on traditional employment to be a source of stability as they took other life risks like starting a family. Now, though, as the number of independent contractors rises and they learn how to navigate the market to easily secure multiple gigs, they believe that they are in a more financially secure spot than they were as traditional employees.

In a note of morbid levity, the takeaway from the article about what employers should do to avoid losing more and more talent to the freelance world is “Obviously, they need to make traditional full-time jobs more appealing, and more secure.” Whoops! Looks like no one has gotten the memo as we go through the largest tech layoff since 2001.

To conclude here, hopefully you can suspend your judgement about my bias long enough to conclude that it may be worth reevaluating any long held position you have about the type of work you’ll allow contractors and third party outsourcing firms to do. You may learn that some of the most talented and loyal developers you’ll ever work with aren’t the ones applying to your job postings but rather the ones that love being able to tackle different challenges across different companies and that may live far from the talent sucking vortex of Silicon Valley.

Thanks for reading!

—Jon Christensen

Then something unexpected happened. I got the worst case of writer’s block ever. I’m sure no one but me is keeping track, but that’s why I haven’t written a new post in a month. For the past four weeks, I would try to get my mind to think about interesting changes in the world of startups—specifically fintech—and it just goes back to thinking about generative AI. I’m obsessed.

I’m chewing on it, digesting it, metabolizing it like some sort of hallucinogenic drug. I catch myself lost in thought about potential GPT-3 business ideas, and everything that comes to mind is too easy, too obvious, or too indefensible.

When I wrote my first post on generative AI and fintech, something I didn’t mention because it didn’t fit the message of the post, is that I wasn’t concerned that generative AI would have a big impact on fintech because most of the work done in fintech doesn’t require generating something new. We need to connect systems and maybe analyze data, but we’re mostly not creating. Except, I thought at the time, for the code that we write to do this work. But I felt fairly certain that truly useful code generation was a ways off. Then a few weeks went by and truly useful code generation happened.

You’ve probably seen this example and better, but just in case, here’s an example of ChatGPT writing code to generate an animation of rain in a web browser.

@joshsowinChatGPT makes simulated raindrops using p5.js #processing #ai #aiart #gpt

Tiktok failed to load.

Enable 3rd party cookies or use another browser

Every developer I know is talking about this right now. We are all transfixed. We are playing with it, and we are already using it to write our code. Coding with ChatGPT, in my mind, is far more valuable and powerful than using it to write prose.

The takes I’ve seen are about how AI could replace junior developers, how we could all lose our jobs, and how developing has just turned into managing the output of generative AIs.

That last statement is the closest to the truth. But I’ve been thinking more deeply about what this all means? How will this play out in the market? What will software become?

Then it struck me. I knew. I know.

We are about to enter a time of vastly more code running on processors than has ever run before. The next phase of fintech, social media, word processing, games, commerce, EVERYTHING will be about personalization. This means personalization not just for consumers but for businesses. Over the past 50 years, to create great products, experienced product managers have had to work some magic to know how to find the greatest common UX denominator across a range of customers and business cases to build products that suited the largest possible addressable market.

Now, huge backlogs of customer ideas and one-off requests squirreled away in product management tools will become viable.

As we go through a huge round of tech layoffs, I’ve noticed some hand wringing and wondering out loud what this all portends for the tech industry. The New York Times did an article about the shrinking job market for recent grads, and an incorrect interpretation of this story is that there is less demand for software.

Au contraire. The demand is there. Customers want changes, updates, features, capabilities. But the economics of building new software—especially in big tech companies, where developers were beginning to feel entitled to total compensation packages worth as much as a $1M per year, made the economics of adding certain types of features difficult. The math is simple, right? If it takes a person year to code it and maintain it, then it better generate well over $1M per year in revenue.

If the same amount of code could be built in a month or a week, then the project would get a green light with hardly any balance sheet scrutiny.

Here’s a personal example: At Kelsus, one of our secret advantages for hiring great people in Argentina is that we have a flexible work and payment structure that allows developers to control how they are paid at the same time as enjoying the benefits and protections of employment by a local company. Over several years, we’ve built sophisticated business processes to manage all this, and I think of it as our mini-fintech. There have been times when we’ve talked about moving away from spreadsheets, Slack, and email to custom coded systems—after all, we are developers. But every time we’ve looked at it, we’ve decided that the amount of code we’d need to write isn’t worth it for our small team. That time and energy would be better spent on a different part of the business. With AI code generation, the equation changes.

In this new world of vastly reduced price-per-feature, each customer—whether in-house or external—will be able to buy products do exactly what they want. Software companies that embrace this new paradigm efficiently by building systems and architectures that enable it will be the most successful.

This new world is here today. Developers are already bragging to each other, teaching each other, and accelerating their craft to unheard of levels of output. 10X developers, 100X developers, and 1000x developers are all going to become real. The future’s 1000X developers will still need to reason, think, combine, derive, and plan. They just won’t need to toil as much. I also still think they’ll be paid very well because they’ll be responsible for building vast amounts of business value. We’ll set aside concerns about whether all this value will be distributed equitably for another post.

The question to me now is whether this all happens over the next 5 years, 5 months, or 5 weeks!

—Jon Christensen

Given a lack of well audited, public open source software for doing banking, and a lack of “here’s how we did it” blogs on the internet from trusted companies like Stipe or Venmo, fintechs need to either hire experienced developers or risk learning some lessons with financial transactions the hard way.

In an effort to make some of these lessons less likely, I’ll enumerate nine common engineering mistakes early fintechs make. Some I’ve drawn from my own experience, and others have come from interviewing members of the fintech community.

1. Security (obviously)

Of course, when money is involved, security is important. Security is a journey, a priority, a process, not a Jira card to complete. That said, there is one thing that I highly recommend everyone pay attention to that I’ve known many developers to be unfamiliar with: the OWASP top ten. I won’t list them here, but these are the 10 most common web application security mistakes as listed by Open Web Application Security Project. The list is kept up to date yearly as practices and tools change.

2. Using floating point data types

Everything stored in computer memory is in binary. When floating point numbers, which in software means numbers that have a decimal point somewhere in them, are represented in binary, they can lose precision. For example ten cents (0.10) in binary is like the number one-third (0.333…) in base ten. It’s a number that goes on forever. It looks like this: 0.000110011001100110011001100110011001100110011001100110011...

If you use floating point numbers to represent currency, computers will have to round them, and when you add up enough money, the rounding errors will start to add up and become noticeable, even substantial. Instead, developers should use integers to represent money and count pennies. If money needs to be divided, and division isn’t even, the extra pennies should be apportioned according to well-understood business rules.

3. Updating transactions

Transactions like credit card payments have a lifecycle with many states—authorized, cleared, voided, returned, declined, etc. It can be tempting for web developers that are used to updating the state of objects in a database to query for an existing transaction and update it. This is against fintech rules because of the financial requirement for audibility. Auditors looking at a ledger need to trust that every entry in the ledger was made at a specific time and has not been manipulated in any way. Fintechs need to build transaction tracking systems that add every transaction (even updates to existing transactions) as new records and to lock down databases so that no one, not even god, can change an existing transaction.

Over the last decade, fintechs using RDBMS databases to record transactions have built features onto their databases like a journal of all changes to all data and clever ways of making sure the data hasn’t been modified by storing checksums of data as transactions are added.

Assuming that fast moving entrepreneurs would like to find a way to get to MVP faster than might be possible with the level of engineering required to make a rock solid, RDBMS ledger system from scratch, here are a few options.

I should note that Kelsus has not evaluated all of these, so this list does not represent my endorsement:

1. This method suggested by AWS to use their QLDB database looks quite interesting. QLDB comes with audibility, write once, and write optimized access built in. It’s worth noting that one fintech architect I spoke to immediately rejected the idea of using QLDB for core banking because it has built-in scalability limitations and doesn’t have reliable market history.

2. I love challenges to the common wisdom, and the common wisdom of fintech is that you shouldn’t use a NoSQL database to store transactions. This is because out-of-the-box these databases are configured to be “eventually consistent.” It’s fair to read “eventually consistent” as “possibly inconsistent at any given moment.” And if a database is inconsistent, someone could, for example, spend the same money more than once. But there are ways, via database configurations and application code, at your own risk, to make NoSQL databases verifiably consistent. If you know that you’re going to have internet scale transaction throughput demands and want to use DynamoDB, here’s an article with information about how: https://decimals.substack.com/p/things-i-wish-i-knew-before-building

3. If you want to build your own ledger on an RDBMS, here’s an article for that (but it doesn’t get into data protection and auditing validation): https://blog.journalize.io/posts/an-elegant-db-schema-for-double-entry-accounting/

4. If you want a managed service to just take care of this for you, have a look at Twisp.

5. And finally if you want a product to do this for you, but want to host it yourself because you are concerned about third party managed service providers, have a look at TigerBeetle.

4. Multitenancy:

If your B2B SaaS app for making charter cruise reservations has a weakness that allows someone from one charter company to enter the id of another charter company into the API and get their data, the worst that can happen is a little unfair charter boat competition. In a fintech, these kinds of multitenancy bugs can lead to money losses and privacy regulation violations. Historically, multitenancy in SaaS has been enforced through careful code review and testing, but data across tenants all went into the same database, and there wasn’t a structural way of preventing a SQL query from returning data across customers. Since 2016, major databases like PostgreSQL and Sequel Server have supported row level security thereby making it possible to make parts of the database invisible to people without permissions. If you use an RDBMS for your fintech, definitely consider it as a way of keeping customer data safe. Here’s an intro about how to use it from AWS.

5. Testing and release management

Deciding how to configure environments—ie dev, sandbox, prod, etc—and how to ensure they are running properly can be a brain teaser in any organization. In fintech, when real money moves on prod, and core functionality depends on numerous third party integrations, it is super challenging. This article is not the place to explain how to do it, but there are three common mistakes to avoid.

1. Many companies have a really confusing or poorly documented path from sandbox to production for third party integrators. Make this path clear, and while you’re at it, do a risk analysis on whether it could ever be possible for a third party to connect to the wrong environment without catching their own mistake.

2. Plan for every important configuration of your production environment to be testable. Testability might require multiple test merchants and test accounts that move real money. You never know when you need to double check that the plumbing is working.

3. An often overlooked requirement is to be able to ensure that the production environment is doing error handling properly. The thing about production systems is that they’re not supposed to have errors, so you can’t see how they performs under error conditions unless you can force errors to happen.

6. Application monitoring

Deploying to a public cloud like AWS means that some infrastructure monitoring can be added quickly and almost as an afterthought, but application monitoring cannot. Even on day one of your launch, the CEO will want to know things like how many transactions are being processed and what their total dollar amount is. Another thing that tends to happen early in the life of a fintech is that there will be a drop-off between signups and usage, and someone on the product team will start asking if users are experiencing errors. Be ready with good monitoring to be able to answer these kinds of questions from day one.

7. SDK and Library support

Kris Hansen, CTO of Synctera, a banking as a service (BaaS) company, gets credit for this one. A problem developers, especially those that love using new tools and frameworks, can run into, he said, is “not considering the SDKs and libraries that you will want to include in your project. Knowing how to wrap and use third party libraries for things like DOCv step up, remote deposit capture, and security features is pretty key these days. If your stack choices make this really challenging you're going to have a hard time.”

I can imagine, for example, some serverless architectures that have a lot of business logic in AWS Lambda functions might make it difficult to do dependency and release management with these types of libraries. It’s also worth considering whether the libraries and SDKs you are using are just wrappers for HTTP APIs. In that case, I recommend using caution. I’ve seen too many bugs in third party HTTP API wrapper libraries over the years to use them without first considering whether it might not be better to just call the HTTP API directly with your own code.

8. Be careful with retry logic

Talking with two time technical cofounder and current fractional fintech CTO Cho-Nan Tsai surfaced a mistake that can lead to a cascading failure. He says, “When integrating with various payment vendors, be sure to set up async queues for those tasks. However, take care with how retries get triggered and handled. We had issues with too many unnecessary retries that blew things up in our system.”

I love this one because it is earned experience. His team was being careful and thinking ahead to do retries on failed API calls, but if a critical system under heavy load isn’t responsive, those retries can pile up.

More generally, I’ve seen both in and out of fintech that unresponsive third party systems are a paved road to cascading system failures. I’d like to suggest that the best—better than code reviews, better than pair programming, better than automated tests—way to prevent getting caught off guard is to do what AWS calls a Game Day. It’s essentially just a risk analysis meeting where developers talk about what could happen when things start going wrong. If you don’t have it as part of your release process, add it. You’ll be amazed at the mistakes you avoid.

9. Loosely defined requirements

Doug Hurst, former Venmo Head of Growth, mentioned this common mistake that might seem like a product rather than an engineering issue, but it falls to the engineering team to avoid.

Engineering teams working outside of fintech may be used to getting product requirements in the form of mockups and high level business requirements. Senior engineers on their own or in informal meetings distill these requirements down to the level of business rules, which get baked into systems and sometimes forgotten.

Doug says, “having your developers write their own requirements,” is a recipe for unexpected issues and slow feature velocity, because “the product dev interface is so crucial.” He went on to say that if you’re at a fintech where this is happening, take the extra time to document the detailed business rules around transaction state management, error handling and retry logic, and account configuration. Schedule time with the product team, even if they are understaffed, to communicate these rules back out to the business.

I asked in a few places for other examples of tech mistakes that fintechs have made and I am sure that I’m leaving out some surprising and facepalm examples. Please reply to this message with some of your favorites, and I can include them in an update next week.

Thanks for reading. Please consider hiring our team at Kelus to do software development for your company. It goes without saying that we don’t need to be trained on these particular mistakes.

—Jon Christensen

Last week I got access to a new AI powered word processor called Lex. Unbelievably, as if I didn’t already devote enough ink on this newsletter to Nathan Baschez, founder and author at Every, Lex was created by none other than… Nathan Baschez.

He wrote the story of how he got the idea and brought it to market in this post. The cliff notes of the story is that he felt like there was room for improvement in online word processing for internet writers, and that adding artificial intelligence to generate writing ideas via GPT-3—a text generating AI from OpenAI—could be fun. He built it as a side project, and released it to the market, and 25,000 people signed up to use it in 24 hours.

My favorite part of the story is that during our market analysis class, which I wrote five posts about, Nathan used word processors as an example market, and at the end of the class, we all knew why.

So, this is the background of this post. I’m writing this post with Lex, and I’m wondering what the fintech equivalent of Lex would be.

Let’s figure it out by using AI to help us. In the rest of the post below, all text written in block quotes with the blue line on the left is generated by AI with no editing other than formatting from me.

In order to see how to do a “Lex of Fintech” we first need to understand the keys to what made Lex’s market introduction a success.

1) There is room for improvement in the user experience of existing products. In the word processor world, Google Docs, and Microsoft Word (and others) weren’t absolutely perfect.

2) Adding generative AI to a word processor is more interesting to writers as a tool than as a replacement. Many other companies were out creating products with the focus of creating whole blog posts or whole articles. Nathan wanted to make something to help writer’s block. Remember the “Jobs To Be Done?” post I wrote? Solving writers block is a job that many writers need done for them, so it’s a brilliant way to position a product against incumbents.

3) Making the experience seamless and intuitive is critical. Other generative AI writing tools were using multiple windows to manage seeding the AI vs producing output. Nathan’s tool just makes use of the existing post that the writer has already been working on as the input, and the writer types “+++” and the AI takes it from there, adding the next 6 or so lines of text.

So with this as a backdrop, is it possible to do the same for some fintech products? I think so.

Lex, how would we do this?

Ok, so the first question to consider is what existing fintech products have room for improvement in the user experience?

One example that comes to mind is online banking. There are a few areas where the user experience could be improved. For example, the process of transferring money between accounts is often needlessly complex. Another example is that it is often difficult to track spending across multiple accounts.

To improve these user experiences, a generative AI like GPT-3 could be added to

suggest money transfers between accounts based on past behavior, or to track spending and offer recommendations for budgeting.

Another example of a fintech product with room for improvement in the user experience is investing. For example, it can be difficult to find information on specific companies and stocks, or to get personalized recommendations for investments.

To improve these user experiences, a generative AI could be used to surface information on companies and stocks, or to make personalized recommendations for investments.

Can you even believe this? I didn’t tell GPT-3 anything about types of fintech or ways that it could be useful. It came up with these suggestions on its own. So it could be that the generative AI that will send fintech rocketing forward already exists, and it is already GPT-3. A way of testing this thesis is to imagine that GPT-3 as a financial advisor:

OK, GPT-3, imagine we’re a couple in our 30s, and we’re about to have our first child. We live in Denver, and we pay $2500/month to rent a one bedroom apartment, and another $800/month in payments for our two cars. To add detail to this picture, let’s say one of us is a paramedic, and the other partner is a mechanical engineer, and our combined income is $9500/month after taxes. We want to get a bigger place for the new baby, but we’re also worried about our jobs in a possible recession.

A financial advisor would suggest that we save up for a down payment on a house, and also create a rainy day fund in case we lose our jobs. They may also suggest we invest in a 529 plan for our child’s future education.

Now, let’s imagine that instead of a financial advisor, we have GPT-3.

GPT-3 would read our situation and then generate a few different options for us.

1. GPT-3 could suggest we save up for a down payment on a house.

2. GPT-3 could suggest we create a rainy day fund in case we lose our jobs.

3. GPT-3 could suggest we invest in a 529 plan for our child’s future education.

4. GPT-3 could suggest we refinance our cars to lower our monthly payments.

5. GPT-3 could suggest we sell one of our cars and use the proceeds to pay down debt.

Each of these options has pros and cons, and it would be up to us to decide which option is best for our situation.

However, having GPT-3 as our financial advisor would give us the benefit of having a tool that can generate personalized recommendations based on our specific situation.

So there you have it. Fintech needs a Lex.

The artificial intelligence came up with ideas for me, explained how they would work, and then circled back and closed out my argument.

Surely there are some fintechs already out there today looking at examples exactly like this to figure out how to incorporate GPT-3 into a workflow.

The ones that figure out how to most seamlessly incorporate GPT-3 into a valuable workflow and position their product as doing a job the market needs done will lead the competition.

Thanks for reading! Let me know what you think of generative AI and what it’s going to do to fintech.

—Jon Christensen

1. Jobs To Be Done

   Startup Win

   Learn market analysis with me

   Right now, I’m in a five week class called Divinations Market Analysis Workshop offered by the business strategy writer and founder of my favorite new media company, Every. I’ve mentioned Nathan Baschez and his company enough times in this newsletter that you’d be forgiven for assuming I’m on their marketing team. I’m just a superfan. I love how clearly…

   Read more

   4 years ago · 1 like · Kelsus

2. Basis of Competition

   Startup Win

   How to get customers

   I’m taking a class from Every called Divinations Market Analysis Workshop taught by one of my favorite writers and business thinkers, Nathan Baschez. This post is about what I learned in week two of the class. Miss week one? I got ya right here…

   Read more

   4 years ago · Jon Christensen

3. Mapping Value Chains

   Startup Win

   Your product value chain mapped

   I’m back from Copenhagen where I spent a week marveling at how beautiful and prosperous the city is. I went for a run on the sidewalks and streets laughing with a thousand people on bikes while we all shielded our eyes from the rain. Also welcome new Nordic readers! I’m so happy to have met you. The Nordic Fintech Week conference was amazing…

   Read more

   4 years ago · Jon Christensen

4. The Law of Conservation of Modularity

   Startup Win

   Applying the Law of Conservation of Modularity to Buy Now Pay Later

   Last week’s class in the Divinations Market Analysis Workshop was heady. The main topic was The Law of Conservation of Modularity. It’s a mouthful to say and was more than I was able to wrap my head around during the 90 minutes of class time. So, when I sat down to write today’s entry (number 4 in this 5 part series), I needed to do some research. So of…

   Read more

   3 years ago · Jon Christensen

5. The 7 Powers

   Startup Win

   In which I call BS on one of the 7 Powers

   This is the fifth and final Divinations Market Analysis Workshop post. If you’ve been reading them, you have powerful new tools for thinking about how products fit into markets. In this post I’ll be explaining the 7 Powers concept by Hamilton Helmer, lifelong business strategist and occasional Stanford business school professor. And, as I’ve been doing i…

   Read more

   3 years ago · 3 likes · 2 comments · Jon Christensen

The speakers on the panel were successful, composed, intelligent, and assumed the audience shared their understanding of the market. At one point, one of the speakers, a fintech founder and CEO, made mention of the progress Europe has made in instant bank to bank transfers, and with a knowing look toward the audience, he said, “We find ourselves a bit ahead of the US in this regard.”

The audience collectively nodded. Everyone was in on it. It goes without saying, or explaining, that Europe’s banking and payments technology is significantly more advanced than that of the United States. But, as many times as I had heard this, since no one had ever explained it to me, I had no idea why.

I decided to find out. I would start with the much narrower question of why Europe has made good progress on instant bank to bank transfer and the United States has not. I started my search on Google looking for a quick ‘splainer, but it turned into a rabbit hole.

First, let’s not just take my word for it that instant bank to bank transfer is further along in the EU than in the US. Here’s a chart of progress in the EU:

Here’s a related chart for the US

Put into context, that $20 billion dollar number looks small at less than 1% of total payment volume in 2021:

In my journey down the rabbit hole, I found three reasons for the discrepancy in payment technology and bank behavior between the US and EU. First, the EU had direct and pressing needs for significant changes in banking as it went form a model of every country for itself to a unified economy in during the aughts. Second, large banks’ resistance to change and regulation is present in the EU, but has been less successful than in the US, where it’s very powerful. And finally, there have been a few key influential and motivated policymakers doing effective leadership in the EU.

The European banking and payments garden was already well tilled

The first reason, that the EU was coming together and needed to change the way it did banking, is rather obvious now that I understand it. Without getting deeply into the reasons that the EU was formed in the first place, we can agree that EU nations were looking for global advantages working as a single unit. Working as a unit necessarily included the way member nations conduct banking and finance, and the most powerful example of that was the formation of the Euro as a single currency that most EU nations adopted. Near the same time as the creation of the Euro, the European Commission, EU’s government branch that proposes new laws and enforces existing ones, set out a vision of a single European payment area, which they dubbed SEPA.

European banks, realizing that they would be forced into action by the new EU government, chose to work together to combine their power into a strong lobbying and policy guiding force called the European Payments Commission (EPC) founded in ‘02. The EPC saw to the details of creating new cross border payments schemes, surely with the interests of the member banks in mind.

If things had stopped there, the EU and US would look similar in terms of payments technology. EU banks would be able to inexpensively send money to each other using newer but functionally similar transit rails to US ACH payments, with easily routable batch transactions and settlement requiring at least a day. Further changes to interbank payments would have been tightly controlled by the EPC and its member banks would have retained their incumbent advantages.

Politics and the power differential between banking coalitions in the US vs the EU

But things didn’t stop there. The EU has recently enjoyed a period of strong political will in favor of robust regulation owing to, among other things, preferences of policy elites, and the administrative and legal criteria for assessing risk. In banking and payments, therefore, the EU had policy experts wanting to sew the seeds of payments innovation—who we will discuss in a moment—and a political environment in Parliament that could pass laws that would create high implementation costs for existing banking institutions in order to protect consumers and promote fair competition.

Contrast that with the political situation in the US where neither of the two political parties can accumulate enough votes in the chambers of Congress to pass new laws, and every issue, regardless of topic or public opinion lands squarely along party lines.

Given this lack of political will in the US to apply new regulations to payments or banking activity, the future is determined by existing powerful banks. When they need to interoperate, they create coalitions to make changes in lockstep while gatekeeping and protecting their market positions. US banks have created these coalitions in response to multiple financial innovations from real time payments (RTP) to cryptocurrencies. The RTP coalition is called The Clearing House and despite benevolent sounding language on its home page claiming to welcome “all federally insured U.S. depository institutions,” its 25 owner banks are statutorily acting to maximize shareholder value for their own institutions which means protecting themselves from competition.

The 77 member banks of the European Payments Commission would likely have arranged Europe’s future of banking and payments in the same anti-competitive way as those in The Clearing House had it not been for some strong leadership from policy makers in the European Commission. Wired magazine did an excellent deep dive on Open Banking in 2017 which I will draw from to highlight the importance of individual policymakers in creating the modern fintech environment in the EU.

The two leaders behind the EU payments and Open Banking transformation

Open Banking was shepherded in by a law called PSD2 which was passed in 2016. It had three main parts.

1. Requirements for strong (multi-factor) authentication for customers to access bank information and initiate payments.

2. Establishment of improved bank to bank transfer capabilities within the Eurozone that are interoperable with third party payments providers (this is the part that leads to instant transfers).

3. Ensuring banks create standardized APIs for third party applications to retrieve product and customer data.

Even though this post is about why the EU has instant bank to bank transfers and the US mostly doesn’t, it’s the third piece of the PSD2 law that is most astonishing. Having witnessed the power of big business lobbying groups on Washington, I can’t wrap my head around the audacity and power of the the Open Banking rule. Big Banks maintain their position by integrating their ownership of customer information and deposits. Forcing them to open up that information to third parties without charging for it is astounding and transformative.

Apparently, the open banking idea was the brainchild of a guy named John Gibson who was excited in the early 2010’s by innovation in other markets with the emergence of data rich APIs like the Google Maps API. He wanted the equivalent of an App Store for banking, and wrote a report for the European Treasury about how it could work.

The result of Gibson’s work is called The Fingleton Report, a thoughtful, and surprisingly readable breakdown of what could be made possible with Open Banking and how to get there. He published it with with Andy Reiss as an independent report for the UK government in 2014. The UK government’s Competition and Markets Authority (CMA) took the study and started running with it. It was a blueprint for banking disruption to be carried out by the banks themselves.

After the PSD2 law was passed and Open Banking turned from a vision to a project in need of implementation, a fintech founder and operator named Imran Gulamhuseinwala was put in charge of the UK’s Open Banking Limited, the organization with the mandate to steward implementation of Open Banking. There, he established himself as a forceful leader working against the inertial stasis of the big banks to get them to develop open and useful APIs.

In his interview with Wired, Gulamhuseinwala talked about how banks had been dragging their feet to begin implementation and were wanting to do the minimum necessary for compliance. One of their largest sources of income, overdraft fees, was on the line because Open Banking would allow third parties to create tools that would warn customers and prevent them from making costly unexpected overdrafts.

But to Gulamhuseinwala’s apparent surprise, and perhaps because the banks already saw the writing on the wall for overdraft fees when the The Financial Conduct Authority listed them as a source of “significant concerns,” the Banks bent to the task of building the APIs, and Open Banking emerged.

Closing

Without the influence of innovators like Gulamhuseinwala and Gibson—along with their willingness to participate in policy and politics—I don’t think the EU’s vision of standardizing interbank information transfer would have resulted in Open Banking. It would have been standardized but decidedly closed like what The Clearing House has done with Real Time Payments in the US. This feat, combined with the EU’s recent momentum in regulation after having taken on the impressive task of pulling 27 countries together into a single economic and political unit, allowed for the fertile ground that has given the EU notable advantages in banking innovation over its friends on the other side of the pond.

Next year, in the US, real time payments might become available to more organizations by way of the FedNow service. The Federal Reserve does not have the same power to push Open Banking rules and regulations that the European Commission enjoys, so it remains to be seen what the level of bank participation and non-bank access will be in the system. Fintechs are clamoring to get on board, and we at Kelsus would love to help with some implementations, so please let us know if you’d like to discuss.

Thanks for reading! Let me know if you think of this post next time watch a panel of experts and you see one of those knowing smirks from a fintech CEO.

—Jon Christensen