I kept ending up in the same room.

Shopify, Deel, Certn, Superside. Different products, different stages, different problems - and somehow the same conversation every time.

Someone had decided the company needed AI. The mandate was clear. The use case was not. Leaders wanted leverage, teams wanted relief, and the people who could build the thing were already three quarters deep in a roadmap that predated the decision.

So I started building instead of advising.

Not slideware. Not theoretical "AI transformation." Actual tools that connected to messy systems, survived real users, and made someone's day meaningfully easier.

That started with AskAxon - a lightweight Slack app that connected to a company's data warehouse or BI layer and let people ask questions in plain English. It was used by 200+ employees at Certn and later by BPD Healthcare's marketing team.

The feedback was obvious: people did not just want answers. They wanted context, charts, dashboards, slides, and a way to turn raw company data into decisions.

That became DataSays - a heavier, standalone AI data workspace that connects to data sources and lets teams move from question to insight to narrative output. Today, DataSays is live with customers including raven.inc and BPD Healthcare, with an active revenue-sharing distribution model being explored with Raven.

At Superside, I'm building another version of the same thesis from a different angle: a Chrome extension that scans Salesforce opportunity, account, and contact pages so sales reps can research accounts, prepare for calls, and move faster without switching between ten tools.

The pattern has become clear.

The hard part was never the model.

The hard part is knowing which problem is worth pointing it at - and being willing to ship the unglamorous version that actually works.

How I got here

I did not come to AI from a lab.

I came to it from operations.

My career has been spent inside companies trying to grow faster than their systems could handle. At Shopify, I learned how large organizations think about data, workflows, support, and scale. At RenoRun, Forma AI, Certn, Deel, and Superside, I worked closer to the chaos: revenue teams, GTM systems, forecasting, dashboards, CRM hygiene, automation, and the everyday operational drag that compounds inside growing companies.

That gave me a specific lens on AI.

I was not interested in AI as a novelty. I was interested in AI as leverage - a way to compress the distance between a question and an answer, between a workflow and an outcome, between a person and the system they need to use.

The moment it stopped being a side interest was when I realized how many AI conversations were being led by people who understood the technology but not the operating reality.

Companies did not need more demos.

They needed someone who could walk into the messy middle, understand the business problem, connect the right systems, build the first working version, and get people to actually use it.

That is the work I do now.

What I learned building at scale

Large companies teach you discipline.

They teach you that adoption matters more than novelty. That governance matters. That "works in a demo" and "works in a real workflow" are completely different bars.

They also teach you that AI does not fail because the model is bad. It fails because the data is messy, the workflow is unclear, the user does not trust the output, or the solution asks people to change too much too soon.

Startups teach you the opposite lesson: speed matters.

You do not have six months to design the perfect architecture. You need to find the sharpest pain, build the smallest useful thing, and prove that someone will use it again tomorrow.

My work sits between those two worlds.

I build with enterprise instincts and startup urgency.

That means I care about the boring things: permissions, data quality, CRM context, adoption loops, user trust, workflow fit, and whether the output is useful enough for someone to change their behavior.

Because that is where AI becomes valuable.

Not in the prompt.

In the workflow.

Why I build instead of advise

Advice is easy to over-polish.

Building is harder to fake.

When you build, the truth shows up quickly. The data does not connect. The user does not understand the button. The output is almost right, but not useful. The workflow works for one person and breaks for the team. The real business logic was never documented anywhere.

That is where I like to work.

I help companies identify where AI can create real leverage, then I build the first version close enough to the work that it can be tested, improved, and adopted.

Sometimes that means an internal sales assistant. Sometimes it means an AI analytics layer. Sometimes it means automating research, reporting, CRM updates, customer insights, or operating workflows that quietly eat hours every week.

I am not trying to make every company "AI-first."

I am trying to make the right parts of the company faster, smarter, and less dependent on manual work.

The best AI tools do not feel like magic.

They feel like someone finally understood the job.

What I'm doing now

Today, I build AI products and workflows for companies that have real operational problems and enough urgency to solve them.

My focus is on B2B teams with messy systems, valuable data, and workflows that are still too manual - especially across revenue, sales, marketing, customer operations, and analytics.

I am building DataSays as an AI data workspace for teams that want to ask better questions of their business and turn answers into charts, dashboards, slides, and decisions.

I am also working with companies that need an AI builder to come in, understand the existing process, and turn it into something smarter: internal copilots, workflow agents, CRM assistants, research tools, reporting systems, and automation layers that actually get used.

A good fit is not "we want AI."

A good fit is: "this process is painful, important, repetitive, and expensive - and we are ready to fix it."

That is where I can help.