Apparently you need the word “built” in your Indie Hackers title. So here it is.

I’m only half joking. Spend a few minutes scrolling through Indie Hackers and you start noticing a pattern. Someone built a SaaS in a weekend. Someone built an AI tool with no-code. Someone built a product after getting laid off. Someone built a tiny app that somehow reached $8k MRR. After a while, “built” starts feeling less like a verb and more like the unofficial SEO strategy of Indie Hackers. And honestly, I understand why. Building is the satisfying part. You start with nothing and eventually there is something you can point at: a landing page, a product, a feature, a checkout flow, maybe even the first Stripe notification. That moment feels tangible. It looks like progress. But the longer I work on products, the more I wonder whether building is actually the easiest part of building something.

The part nobody puts in the title

The headline usually says: I built X. The real story is rarely that clean. You had an idea and wrote it in Notes. Then you discussed it in Slack. Someone sent feedback through email. You copied part of it into Notion. A task appeared in Linear. Another person sent a screenshot through WhatsApp or Telegram. Someone updated the Figma file but forgot to mention it. Two days later you vaguely remember that there was an important comment somewhere, but you cannot remember whether it came from email, chat, a meeting transcript or one of the fifteen browser tabs you still have open. Eventually you gather enough context, understand what you were supposed to do, and finally build the thing.

The actual implementation might take four hours. The coordination around it somehow takes three days. Yet nobody writes an Indie Hackers post called “I spent six hours figuring out which message contained the feedback I needed.” Nobody proudly announces that they spent twenty-five minutes reorganising a task system in order to theoretically save ten minutes next Thursday. These things are too boring to become founder stories, but they are a huge part of what work actually looks like, especially if you are operating alone or in a very small team.

And apparently, it’s not just a feeling.

Atlassian’s State of Teams 2025 research surveyed 12,000 knowledge workers and 200 executives and found that teams and leaders spend around 25% of their time simply searching for answers. Not doing the work. Not making decisions. Not creating something. Searching for enough information to be able to continue.

A quarter of the week isn’t being lost because the work itself is particularly difficult. It’s being lost trying to reconstruct the context required to do it.

That feels like a much bigger productivity problem than whether your task manager has the perfect keyboard shortcut.

We’ve optimised the visible part of work

What makes this especially strange is that almost every visible part of building has become dramatically faster. Writing code is faster. Research is faster. Designing interfaces is faster. Creating prototypes is faster. Writing copy is faster. We have spent years improving the tools that produce the final output, and AI has pushed that acceleration even further.

But there is an awkward side effect. The faster the actual work becomes, the more noticeable everything surrounding the work starts to feel. Finding the right file. Understanding what changed since yesterday. Remembering what somebody asked for. Turning a random client message into an actual task. Deciding whether something is urgent. Moving information between tools. Figuring out which project a request belongs to. None of these things are particularly difficult, and that is almost what makes them dangerous. They are small enough that we rarely measure them, but frequent enough to constantly break concentration.

Microsoft found something interesting when it looked at how people actually spend their time inside Microsoft 365. Across the apps it analysed, the average employee spent 57% of their time communicating 5 meetings, email and chat 5 and 43% creating in documents, spreadsheets and presentations. The research combined a survey of 31,000 people across 31 countries with Microsoft 365 usage signals. The same study found that 62% of respondents said they struggled with spending too much time searching for information, while 68% said they didn’t have enough uninterrupted focus time during the workday.

Obviously communication is work. Meetings matter. Email matters. Coordination matters. The point isn’t that the 57% is wasted.

But it’s still a strange ratio when you think about how much software we’ve created specifically to make the other 43% faster.

Maybe the next productivity breakthrough isn’t making the 43% faster.

Maybe it’s shrinking the 57%.

You do not finish a day thinking, “I spent two and a half hours on operational overhead.” You remember opening Slack for a second. Then email for a second. Then updating a task for a second. Then searching Drive for a second. Then checking a comment because you were already there. Then opening another app because that comment referenced something else. Each interruption feels insignificant in isolation. Add fifty or sixty of them together and you suddenly understand why you worked all day without feeling like you actually built very much.

Maybe “built” is the wrong unit of progress

Founders naturally think in outputs. Features shipped. Pages launched. Products released. Users acquired. Revenue generated. These are easy things to talk about because they are visible and measurable. But modern knowledge work contains an enormous layer before the output appears. The raw material of work arrives as fragments: an email, a voice note, a document, a screenshot, a comment, a message, a meeting note, a thought written at 11:47 PM. Someone has to take all of those fragments, understand what they mean, connect them to the right context and transform them into something actionable.

That transformation is mostly invisible, but it is still work. And if you are a freelancer, solo founder or member of a tiny startup, there probably is not an operations team quietly doing it for you. You are the designer, developer, salesperson, project manager, customer support person and the person responsible for remembering that a client asked for “the slightly less blue version” somewhere in a forty-six-message WhatsApp conversation. We talk a lot about wearing many hats as founders. We talk much less about how much energy gets spent simply moving information between those hats.

There’s another number that makes this even more interesting. Asana’s Anatomy of Work Global Index 2023, based on a survey of 9,615 knowledge workers around the world, found that people were using an average of 10 apps per day. The same research estimated that 62% of the workday was being lost to repetitive, mundane tasks.

Ten apps.

Not ten apps installed on your phone. Ten apps used as part of the working day.

Any one of them might be excellent. Ten excellent tools can still create a terrible way of working if the user becomes the integration layer between all of them.

This is actually why we started working on Hyzo

We did not start with the assumption that the world needed another project management tool. There are already more than enough places where you can create a task, put it into a column, assign a deadline and attach a label. The question that kept coming back to us was slightly different:

Why does so much modern work still require a human being to manually translate information into organisation?

Imagine a client sends an email saying:

“Can we move the launch to Friday, update the hero section and send me the new version before noon?”

Most software still expects you to do the rest. You create the task. You extract the deadline. You decide the priority. You associate it with the correct project. You maybe create another task for the launch date. You add the relevant context and perhaps paste part of the email into a description so that you remember why you are doing it three days later.

The strange thing is that the information already existed. The request was clear. The deadline was there. The intention was there. We are simply performing an extra translation step between communication and execution because our tools have historically been unable to understand what the communication means.

That is the problem we started exploring with Hyzo. What happens if messages can become suggested tasks? What if files can produce actionable work? What if the system can understand enough context to suggest a project, priority or next step instead of asking the user to manually organise everything? The deeper we go into that idea, the more I think the interesting problem is not really task management at all.

It is context management.

AI gave us faster tools. It also gave us more tools.

There is another slightly ridiculous thing happening right now. AI was supposed to simplify knowledge work, but for many of us it has simply created another layer of software on top of the software we already had. We still have email, Slack, Notion, Figma, Linear, Google Drive and whatever else was already part of the workflow. Now we also have ChatGPT, Claude, Perplexity, a coding assistant, a meeting summariser, an automation platform and three AI tools we signed up for last month because somebody posted an impressive demo on X.

Every one of those products can be useful individually. The overall system can still be chaotic.

And the Asana number keeps coming back to me here: 10 apps a day.

The problem might not be that we need one app capable of doing everything. That usually creates another monster. The problem might be that the human currently has to understand how information moves between all of them.

You receive something here.

You remember it there.

You manually convert it into a task somewhere else.

You attach a file from another place.

Then you update a status so another person knows what happened.

The human becomes middleware.

This is why I am increasingly sceptical of productivity products whose main proposition is simply giving us another place to organise our work. If the problem is that information is already scattered across too many places, creating a better dashboard for manually collecting it may not be the real solution.

The more interesting question might be:

How much organisation can software remove from the user entirely?

Instead of asking where a task should live, maybe the system should understand where it belongs. Instead of asking us to copy context into a description, perhaps the context should already travel with the work. Instead of opening a project manager every twenty minutes just to keep it accurate, maybe the project manager should be paying attention to what is happening elsewhere.

The future might involve less “managing work”

For years, productivity software has gradually trained knowledge workers to behave like tiny database administrators. Create a task. Choose the project. Select a status. Add a label. Set a priority. Assign a person. Pick a due date. Move the card. Update the status. Add another comment. Move the card again. None of these actions are unreasonable, and individually they take seconds, but collectively they create a surprising amount of ceremony around doing the actual thing.

AI creates the possibility of changing that relationship. A client email arrives. The system understands that it contains a request. It recognises which project it belongs to. It identifies the likely deadline. It creates or suggests the next action and keeps the original context attached to it. The person does not need to become a full-time administrator of their own work. They simply confirm, adjust if necessary and continue.

That sounds like a relatively small improvement when described as a single interaction. But work is made of hundreds of these interactions. Remove enough tiny administrative decisions and the experience of the entire working day changes. You spend less time maintaining the representation of your work and more time actually doing it.

And this is where I think the productivity conversation sometimes goes in the wrong direction. We keep asking how AI can help us write something faster, generate something faster, design something faster or code something faster. Those are obviously useful questions. But if Microsoft’s 57/43 split is even remotely representative of the broader problem, there might be a bigger opportunity sitting outside the creation itself.

Maybe AI’s most valuable job isn’t producing more work.

Maybe it’s removing the work around the work.

Anyway, I built this title

So yes, apparently you need the word “built” in an Indie Hackers headline.

Mission accomplished.

But after noticing how often that word appears, I started thinking that maybe some of the more interesting founder stories are not really about what we built. Maybe they are about the unnecessary steps we managed to remove before the building could happen.

We are currently obsessed with making execution faster, and that makes sense. But if teams are spending around 25% of their time searching for answers, employees are spending more time communicating than creating, and knowledge workers are bouncing across 10 apps a day, perhaps there is another layer of the productivity problem sitting right in front of us.

Shipping faster is useful. Better tools are useful. Automating individual actions is useful.

But needing fewer steps to get from “someone asked for something” to “I know exactly what I need to do next” might be even more useful.

And that feels like a much more interesting thing to build.

What’s the most ridiculous piece of “work around the work” you still do manually every day?