In software development there is a concept called cohesion.

It works like this. Suppose you have the following functions:^[1]

function getArea(radius) { ... }

function getCircumference(radius) { ... }

function sendWelcomeEmail(user) { ... }

function updatePassword(user, newPassword) { ... }

function getTemperatureInFahrenheit(temperatureInCelsius) { ... }

function getTemperatureInCelsius(temperatureInFahrenheit) { ... }

You want to group similar functions together. Suppose you created the following modules:

// module-one.js
export function getArea(radius) { ... }
export function sendWelcomeEmail(user) { ... }

// module-two.js
export function getCircumference(radius) { ... }
export function getTemperatureInFahrenheit(temperatureInCelsius) { ... }

// module-three.js
export function updatePassword(user, newPassword) { ... }
export function getTemperatureInCelsius(temperatureInFahrenheit) { ... }

This wouldn't make sense. The modules would each have a low degree of cohesion since we grouped unrelated functions together, and this is undesirable.

Now imagine that we did this instead:

// geometry.js
export function getArea(radius) { ... }
export function getCircumference(radius) { ... }

// user.js
export function sendWelcomeEmail(user) { ... }
export function updatePassword(user, newPassword) { ... }

// temperature.js
export function getTemperatureInFahrenheit(temperatureInCelsius) { ... }
export function getTemperatureInCelsius(temperatureInFahrenheit) { ... }

Much better, right? Now we have grouped like with like. Now our modules each have a high degree of cohesion. The functions in geometry.js are each related to geometry, the functions in user.js are each related to users, and the functions in temperature.js are each related to temperature. This is desirable.

The concept of cohesion applies beyond programming though. Consider restaurants:

Appetizing Alice's:
- Pad thai
- Chicken parm

Bob's Bistro:
- Meatball sub
- Pork tacos

Carnivore Carol's:
- Tom kah gai
- Carne asada

Low cohesion. What about this?

Thai on Main:
- Pad thai
- Tom kah gai

Italian on Third:
- Chicken parm
- Meatball sub

Mexican by the river:
- Pork tacos
- Carne asada

High cohesion. Now we've grouped like with like.

You could do the same thing with stores. A convenience store has low cohesion whereas a book store has high cohesion. Relatedly, a large grocery store has lower cohesion than a high-end cheese shop.

Business problems

I'm in the process of looking for a startup idea to pursue. I'd like to pursue this as a solo founder and I'm looking for something that is moreso a "lifestyle business" than a "swing for the fences" type of business. Something "indie hacker-y".^[2]

Given this, I've heard pretty consistently that I should aim for:

• B2B not B2C.
• Something that is monetized straightforwardly via payments as opposed to something like ads.
• Something that is priced in the ballpark of hundreds or low thousands of dollars a month. Maybe a rabbit or a deer, not a mouse or whale.
• Something where I can do customer acquisition through sales, but that doesn't have sales cycles that are too long.

Makes sense to me. So then, I've spent some time exploring different industries, looking for an idea to pursue.

As I do this I've been noticing something that is making my job difficult: the problems people face seem to have a high degree of cohesion. Let me explain.

Suppose you own a bike shop. You have various problems. Various needs.

• A way for customers to pay you. Traditionally you'd have a cash register and a cashier. The customer hands the cashier some bills, the cashier hands the customer their product, receipt, and any change they are owed. Nowadays customers use credit cards and stores use POS systems.
• To maintain an appropriate level of inventory. If customers want something and you don't have it in stock, that's bad. If you have lots of a certain item in stock and customers aren't buying it, that's also bad.
• Accounting. I don't really know much about what's involved here.
• To make data-informed decisions. This can be teased apart and broken into a need that is more "terminal" and less "instrumental", but let's go with it. If a certain brand of bike helmet isn't selling well, you may want to drop it. If one is selling very well, you may want to consider increasing the price.

There are more, but let's stop there.

I don't know much about bike shops so I'm guessing a little bit here, but it seems to me that these problems are closely related. There is a relatively high level of cohesion at play here. When a customer purchases a product:

• It'd be nice if whatever you use for your inventory tracking was updated. "Now we have one less XYZ brand bike helmet."
• It'd be nice if the revenue being tracked in your accounting stuff was incremented the corresponding amount.
• It'd be nice if you were able to incorporate this data into decisions about pricing or what hours you keep the store open.

So then, I think there's something "natural" and "efficient" and "appropriate" about bike shops having a single all-in-one piece of software to handle all of this stuff for them.

In theory this isn't actually necessary. Instead they could use four different pieces of software, and these pieces of software can "talk to each other". Your POS system exports data that your inventory software imports and uses. But I strongly suspect that this is often not possible in practice.

Think about it from the perspective of the inventory software. You need to import data from the POS system, but how do you know what the format and structure of this data is? I doubt there's a standard structure that is used across all POS systems.

So you'd need to know about the structures that different POS systems use and parse the data accordingly. But that means the user of the inventory software has to input information about the POS system they use, which is added friction.

Suppose they're ok with this friction. What happens when the POS system doesn't have an option to export data? After all, if the POS system is part of a bigger all-in-one bike management app, it's probably in their interest to do this. Just like how Apple doesn't want iMessage messages to be available to Android users. Instead, Apple wants you to buy an iPhone.

There's also the issue that the act of shopping for software is just not something bike shop owners want to be doing. They'd rather get it over with once and for all with an all-in-one solution. They don't want to do it four separate times: one time for a POS system, a second time for inventory management, third for accounting and fourth for data analysis.

So... yeah: I feel like there is something "cohesive" about the problems that this hypothetical bike shop owner faces, and that many businesses face. Something that calls for "all-in-one apps".

And this really makes it hard for me as an "indie hacker" to do what people often recommend: solve one very specific problem. Find a niche. Something narrow and focused. "Zoom in". This works in areas where problems have low cohesiveness, but not when they have high cohesiveness.

At least that's how it seems to me. Maybe I'm missing something.

But if I'm right, then I think my path forward involves looking for places where business problems have a low degree of cohesiveness.

Beyond business

I'm sure this applies beyond business problems. I don't see why it wouldn't.

I haven't thought much about this but I wouldn't be surprised if it had some important implications.

1. ^{^}

   I much prefer arrow functions but chose to use the function keyword because it's clearer to people who don't program or who don't program in JavaScript.

2. ^{^}

   I don't know how to better describe this. I don't think better terminology actually exists.