I have spent the last 18 years working in technology, including around six years as a CTO in startups.
Architecture, cloud infrastructure, engineering teams, incidents, and delivery deadlines are familiar to me. This is also my second time as a co-founder, but my role is different now.
At CatechLabs, I work across product, sales, customer discovery, positioning, partnerships, and strategy.
That shift made something clear: knowing how to build software is not the same as knowing how to build a company.
I am still learning the second part.
We talk to customers, test ideas, send proposals, adjust the scope, and learn from what does not work.
In 2026, creating software is much faster than it was a few years ago.
AI helps with research, prototypes, interfaces, code, documentation, and integrations. A small team can now build in days what might previously have taken months.
Because software is easier to build, it is tempting to treat shipping as progress. A working prototype does not prove that there is a business behind it.
Many products use the same models, interfaces, and promises. Building is easier; finding a real problem and earning trust are not.
My instinct as an engineer is still to start solving immediately. Now I first try to understand who has the problem, what it costs, whether it is a priority, and who has the authority to buy.
It is possible to build the wrong product very efficiently.
One of the most useful parts of this journey has been spending time with customers and the people who run the processes we want to improve.
Not to present the product. Just to understand how the work happens today.
I look for where time is lost, which steps are manual, where mistakes happen, and what result would justify changing the current process.
Customers are often polite. They may praise a demonstration or say they would use the product. That does not mean they will buy.
The stronger signals are urgency, budget, access to the decision-maker, willingness to run a pilot, and commitment to changing the process.
Sales conversations have also become a source of product information. Objections show what is unclear. Unanswered proposals and lost opportunities often reveal problems with urgency, positioning, price, or trust.
During a customer conversation, someone asked:
Why should we pay for your platform instead of simply giving our team access to Claude?
My first instinct was technical. I thought about retrieval, permissions, orchestration, integrations, security, and data architecture.
Those points were relevant, but they did not answer the real question. The customer wanted to know what would change in the operation.
That conversation changed how we explained the product. Instead of starting with models and agents, we started with the workflow.
People were manually collecting information, reviewing documents, checking inconsistencies, and repeating similar analyses across multiple cases.
The value was not access to an AI model. It was making that process faster, more consistent, traceable, and easier to review.
We gave less attention to generic chat features and more attention to structured workflows, audit trails, integrations, and human validation.
A general AI tool can help one person complete a task. A business system needs to make that process work repeatedly across a team.
As part of this transition, I have been studying areas that were less central to my work as a CTO.
Some of the books that keep coming up in conversations with founders are:
I also follow Lenny’s Newsletter, which shares practical lessons on product, growth, leadership, and company building.
None of these references provides a formula.
They help me ask better questions, avoid obvious mistakes, and learn faster.
Building software is faster than ever.
Building something valuable is still difficult.
That is what I am learning now: how to move beyond technology and build the company around it.
CatechLabs is still early, and I am documenting the lessons as we build.