I work with studios and service teams on how client work runs.
Sometimes the answer is a system. Often it is a smaller change to how the team already works.
Small teams rarely start from nothing. They already have software, AI tools, files, and ways of working that have grown around each other. But the work still holds together through people moving context, checking the same answer in several places, and remembering what happens next.
I look at that whole setup: the tools, the sources, the handoffs, the shared context, and the decisions that still need a person. Then I work out what can stay, what should change, and where an existing tool is enough.
If there is still a gap, I decide whether it is better to buy, connect, or build. I do not assume the answer is custom software.
I do not need to map the whole company before doing useful work. I start with one live part of client work or one real client case. It might be a research project, the way a team shares context, monitoring nobody can maintain by hand, or one repeated process that has become expensive.
That is usually enough to see how the wider system works and keep the first scope bounded.
Sometimes the problem is visible but the right response is not. I spend a few days going through the current work, tools, source material, and constraints. The result is a recommendation on what to leave alone, what to change, and whether to solve the remaining gap with an existing product or a custom build.
Often the team already has most of what it needs. I can structure shared team context and client-specific context, define instructions, handoffs, and review points, then test the new setup on the team's actual work. The goal is a system people can use together, not a better prompt for one person. A focused first implementation usually takes one to two weeks.
If the current tools cannot close the gap, I can build the missing part. That may be a bounded workflow, an internal tool, an agent, or a data/LLM pipeline. The scope stays tied to one finished result and starts with the team's material.
I trace how the work moves through the team: where context lives, which sources can be trusted, where handoffs break, and which decisions still need a person.
Then I test the smallest useful change on live material. Sometimes that means a shared context structure or a better way to use a tool the team already pays for. Sometimes it becomes a workflow or a separate product.
The work is finished when a specific person can use it, the team knows what belongs where, and the places that need judgment are clear.
Feely is a brand and web design studio. The team was already using AI, mostly through browser chats, but each task still involved bringing the client material back in and reconstructing where the project stood.
I moved that work into a file-based system where each client has a growing body of context. The history starts with the inquiry and call transcript, then carries into the proposal and the rest of the project. By the time the team writes the final case study, the earlier material is still there.
The change did not come from a faster model. The context was already there, the path through the work was repeatable, and the person doing the work still reviewed the parts that needed judgment.
Feely is the clearest client example, but it is the simpler edge of the systems I work on.
Before working independently, I spent 9+ years in product, most recently as a Senior PM at Everypixel. I worked on AI-powered image search and helped turn internal ML models into B2B APIs. The search product grew to 200k+ monthly active users.
Since 2024 I have built independent AI products that put the same kind of judgment around less predictable model output.
Oriform turns a plain-language request into editable 3D geometry, with preview, review, versioning, and export around the generated result. Use Case Library turns patent records into published AI use-case pages through structured generation, evaluation, and quality gates.
These are independent products. I include them because they show the technical range behind the consulting work. If the work needs a separate product, an agent with state, or a data pipeline with checks, I can design and build that first system rather than stopping at workflow advice.
I keep the first scope bounded and tie it to a finished result. I do not start with an open number of consulting hours or a large transformation plan.
The system keeps a person in the loop where an error has a real cost. I do not promise a fully autonomous workflow, and I do not assume that every manual decision should disappear.
Heavy production integrations, archive migration, external data or licenses, and work that needs specialist engineers are scoped separately. If a delivery partner is needed, that should be clear before implementation starts.
The first call is for a team that knows its way of working has to change, but does not yet know whether to improve the current setup, buy another tool, or build something of its own.
Bring one live example of the work. In 30 minutes, we can look at what is actually getting in the way and whether there is a useful first scope. If there is, I will explain where I would start. If there is not, I will say that too.