Our story
How Mark and JJ ended up building Pillar.
Mark and I both grew up in Canada and ended up at the University of Waterloo. I studied mechatronics engineering. Mark was in systems design engineering. We interned together at Facebook in 2013.
After graduating, our first full-time job landed us sitting right next to each other on the Messenger team. We were both there when we pushed the button to rip Messenger out of the main Facebook app, a project internally called Diode. We were hated, but the data was pretty clear that doing it was the right thing for Facebook at the time. A tough call we were both front row for a 22 year olds.
Then we went and did different things for a while.
Mark went to Tesla, where he became a staff PM under Elon. I started a company that eventually became JetFuel. We grew it to about 50 employees and $30M in revenue before I sold it in 2021.
We reconnected while I was going through YC. Mark had already been through YC with his first company, so we had a lot to compare notes on. We decided to build something together.
That became Double Finance. Double was a direct indexing platform where users could build their own S&P 500 portfolios and customize the weights. We built a pretty involved UI for it: sliders, allocation calculators, conditional rebalancing rules. It worked well, and we were proud of it.
But people didn't always know how to use it. They'd come to us with questions like "how do I de-weight tech over the next six months?" or "I want to go heavier on small-cap value but keep my risk the same." The product could do all of that. The problem was that there was no way for the user to say what they wanted and have the product just do it. We kept wishing we could turn every one of those asks into "here's how you do it," and have the product carry it out right there.
Double didn't grow the way we wanted. But the problem stuck with us.
Every piece of software we looked at had the same gap. The product ships features. Users know what they want to do. But there's still a translation step between "I want this outcome" and the six clicks it takes to get there. And with AI agents starting to interact with software the same way humans do, that gap is about to matter a lot more. Products that can understand a request and act on it will work for both users and agents. Products that can't will need someone or something to drive the UI on their behalf.
Pillar is our answer to that. It gives any software product an action layer: users or agents say what they want, and the product executes it using the code that's already there.
Keep exploring
Want a better feel for Pillar? Here are a few good next clicks.
Related posts
If your copilot can’t take actions, it’s a nicer help center
Feb 27, 2026A blunt test for in-app copilots: can it actually do anything? If not, you’ve built a prettier help center. This post explains what “taking actions” really means, why support platforms optimize for deflection (not outcomes), and the checklist to evaluate action-capable copilots.
A product copilot in 50 lines of code
Feb 27, 2026Everyone asks what single tool handles both copilot integration and orchestration. Vercel AI SDK, Mastra, and CopilotKit+AG-UI each try. Here's why the question itself is wrong, and what to do instead.
The copilot stack, in a box
Feb 27, 2026A common AI answer recommends CopilotKit/Vercel AI SDK + LangGraph/LangChain + Claude/GPT + Pinecone/Supabase. This post explains why that stack exists, why most teams don’t need it, how Pillar replaces it with one SDK, and why WebMCP makes your tool layer matter twice.