What’s Your Setup?

Building a digital business used to involve a fairly clear division of labor: someone designed the experience, someone developed it, and specialists handled infrastructure, data, security, marketing, and operations. My own setup shows how those boundaries are becoming less clear, because tools now let me work across more of those responsibilities myself.

I use Codex CLI when I want to work directly with code and repositories, and Lovable when getting an application's basic structure and infrastructure in place quickly is more useful than starting from scratch. ChatGPT serves a different purpose: it helps me work through decisions, challenge assumptions, research unfamiliar areas, and connect information across a project.

Around those tools are the systems a particular project needs: GitHub, databases, analytics, automation, APIs, email platforms, customer relationship management (CRM) systems, and other specialized services.

The change becomes more useful when those tools work together. I can examine a product problem, inspect an existing system, challenge my assumptions, turn what I've learned into implementation work, and test the result with fewer handoffs across people or applications.

For someone building a digital business, that creates leverage, but it doesn't expand time or expertise at the same rate. Being able to work across more of the business means taking responsibility for areas I may not understand equally well.

Bringing thinking and implementation closer together

I don't use every tool for the same purpose. Codex CLI is useful when I'm working directly with an existing codebase. Lovable can help establish the foundation for something new without spending unnecessary time assembling common pieces of infrastructure. Other tools become relevant depending on what I'm building and what the organization already uses.

ChatGPT has become particularly useful before implementation begins. I certainly use AI to help produce research, writing, documentation, analysis, and code, but some of the larger gains have come from using it to examine how I'm approaching a problem before deciding what to produce.

Before implementation, I find it useful to distinguish between asking AI for an answer and using it to examine the question. A structured conversation can help with the second.

One approach I use is CRIT: provide the context, establish an appropriate role, interview the problem, and then define the task. The framework matters less than the space it creates to examine assumptions, missing information, constraints, and evidence that could change the direction before deciding what to produce.

That interview step becomes more useful as building gets easier. Describing an application, generating an interface, connecting a database, and beginning implementation can happen quickly, which helps exploration but can also accelerate the wrong solution. I'd rather spend some of the time AI saves examining the problem before turning it into work.

This doesn't remove bias. AI systems have limitations, and their responses are shaped by the information and framing we provide. If I misunderstand the problem or provide incomplete context, a confident response doesn't make the underlying assumption correct. The value is in having another way to pressure-test the thinking, not in treating the output as an independent source of truth.

The chat interface can become a working layer across systems

Another important change is the ability for AI environments to interact with other systems rather than working only with information pasted into a conversation.

Model Context Protocol (MCP) is one example. In practical terms, MCP provides a common way for an AI system to access approved tools and information outside the conversation. Public connectors can provide access to commonly used services, while custom connectors can expose specific capabilities from software you build yourself.

For someone who isn't interested in the protocol itself, the practical benefit is fewer manual handoffs between systems. A conventional workflow might involve finding information in one application, copying it into another, interpreting the result somewhere else, and returning to the original system to act. Secure connections can bring more of that sequence into a common conversational interface.

The same idea can influence how new applications are designed. A product can still provide a conventional interface for people who want to use it directly while also exposing carefully controlled capabilities for agents or other systems. The graphical interface remains useful, but it's no longer necessarily the only way to operate the product.

For a small business, founder, or independent consultant, removing those handoffs can free up time for the decision or outcome instead of moving information between tools. But easier connections also make it tempting to automate a process simply because the capability is available.

Not every efficiency is worth pursuing

As the cost of experimentation falls, almost every repetitive task can start looking like an automation opportunity. A new connector appears, a different model becomes available, or another development tool promises to remove a step from the process. It's easy to spend significant time improving something that was never a meaningful constraint.

I sometimes think of this as finding a dollar on the ground. Picking it up makes sense if it's already in front of you. Crossing several streets to retrieve it changes the calculation.

Technology can create the same problem. An automation that saves hours of repeated work may be worth building and maintaining. An automation that saves a few minutes each month may not justify the time spent designing it, testing it, fixing it when another system changes, and remembering why it exists six months later.

Each addition becomes part of an operating environment that may need attention later. I want to understand whether the recurring benefit is worth the setup, maintenance, and complexity, rather than treating the ability to automate something as sufficient reason to do it.

More capability also means more responsibilities

The responsibilities created by AI-assisted building deserve consideration alongside the capabilities. A small business owner, founder, or consultant can now build a website or application, configure a database, automate a workflow, analyze customer behavior, produce content, and connect systems without assembling a large technical team.

That's useful, but the tools don't automatically provide the depth of expertise that previously sat behind each responsibility.

I can configure a database without being a database security specialist or deploy an application without years of experience managing production infrastructure. Generating and analyzing content doesn't necessarily improve my understanding of its audience, and automating a process doesn't tell me whether the process itself should change.

The risk extends beyond an incorrect AI answer. An individual or small team can now operate across more areas than they have time to understand deeply, while remaining responsible for the security, maintenance, and customer experience of what they create.

Applications still need updates, data needs maintenance, and customer needs continue to change. New capabilities add possibilities while existing systems still require ownership, so the responsibilities can grow faster than the time available to manage them.

For organizations with limited budgets and staff capacity, this tradeoff matters. AI-assisted tools can make work possible that would previously have required outside help, but the ongoing ownership of what gets created should be part of the decision to create it.

Attention becomes a practical constraint

Better tools can remove technical bottlenecks without expanding an individual's attention at the same rate. I can work across product strategy, development, content, analytics, automation, infrastructure, and customer experience more easily than a few years ago, but giving each area sustained attention is still a constraint.

That makes awareness of blind spots useful. Working effectively with AI includes recognizing gaps in our understanding and deciding what they require, rather than assuming the system has filled them.

Depending on the situation, I might use AI to investigate further, learn the subject more deeply, or involve someone with more relevant expertise. Being able to do more myself doesn't remove the value of knowing where my understanding stops.

This is particularly important in areas where mistakes carry meaningful consequences, such as security, privacy, financial systems, or sensitive customer data. The fact that a tool makes implementation accessible doesn't reduce the importance of expertise where the risk warrants it.

As tooling becomes accessible, differentiation moves elsewhere

For anyone building a digital business, more accessible tools also change where a durable advantage might come from.

Specialized technical knowledge has historically created a meaningful barrier between an idea and the ability to implement it. That barrier is becoming smaller. If Codex helps me work more effectively with a codebase, the same capability is available to many other builders. If Lovable reduces the work required to establish an application, it reduces that work for other founders as well. As standards such as MCP become more common, connecting AI systems to external capabilities will become less unusual.

The tools remain useful, but widespread access makes them less defensible as a source of long-term differentiation. More of the advantage may come from assets that take longer to develop.

Useful data is one example, although a database isn't automatically a moat. Its value depends on information that's difficult to reproduce, relevant to the problem, maintained well enough to trust, and understood well enough to improve decisions or customer experiences.

An audience works similarly. A large email list or follower count doesn't by itself establish an advantage, while the relationships, trust, distribution, and understanding of what people care about can be harder to reproduce.

There's also accumulated context between those two things. Over time, a business learns how customers describe their problems, where existing solutions fall short, which constraints repeatedly appear, what people are willing to pay to solve, and which seemingly important problems rarely lead to action.

AI can help organize and analyze that accumulated context, but a competitor's access to the same model doesn't give it the same customer history, relationships, distribution, or understanding. Those assets may become more important as the mechanics of building become more accessible.

A better question than which tools are in the stack

I still find other people's setups useful because they reveal how someone organizes information, develops software, uses AI, and removes handoffs. The tools can suggest better ways of working, even if they're only part of what makes the work valuable.

A capable setup can make experimentation practical for organizations that couldn't previously afford it, helping a small team move from an idea to working software, content, analysis, and connected systems. It can also create more software to maintain, data to protect, decisions to make, and areas where shallow understanding creates risk.

That's why I'm becoming less interested in the stack itself as a source of differentiation and more interested in the customer understanding, useful data, context, distribution, trust, and judgment around it. The setup gives me more room to act; those other assets help me decide where the work is worth doing.

A powerful setup can help a small team accomplish much more than before. Keeping that capability focused on problems worth solving remains part of the job.