Project
OpenGraph.io
Lead Product Engineer
Developer SaaS platform for retrieving, extracting, and working with data from webpages.
React · Next.js · TypeScript · Node.js · PostgreSQL
Overview
OpenGraph.io is a developer SaaS platform for retrieving, extracting, and working with data from webpages. I lead day to day product and engineering across the platform, including APIs, dashboard experiences, developer tools, onboarding, analytics, and the marketing site.
From one API to a broader platform
When I joined, OpenGraph was essentially one core Link Preview API, a minimal WordPress marketing page, a relatively simple dashboard, and a product primarily centered around metadata retrieval.
My initial role was much narrower. I was learning the product, supporting customers, fixing issues, and improving the dashboard. That foundation set up a gradual expansion, not a sudden takeover, but a progressive deepening of ownership as I got closer to users and the business.
What I own
I became closer to customers through support. That exposed problems and opportunities. I started shipping additional API capabilities and improving the product around them. Over time, I increasingly became responsible not just for implementing features, but for deciding what should be built and why.
Today my work spans the entire product lifecycle: product discovery → prioritization → UX → engineering → launch → analytics → customer feedback → iteration.
How the product expanded
OpenGraph evolved across three broad areas without becoming a feature catalog:
APIs
The original Link Preview API expanded into additional capabilities around extraction, rendering, screenshots, Markdown, and other webpage data.
Product experiences
The dashboard evolved beyond managing an API key into Site Audit, API playground workflows, onboarding, usage visibility, and other developer experiences.
Marketing and acquisition
The original single marketing page became a larger product driven site with free tools, educational content, dedicated product experiences, and paths from free usage into paid products.
Project: Turning link preview traffic into Site Audit
Signal
The free Link Preview Tool was attracting significant usage and had become a major source of interest in the product.
First assumption
The initial approach was essentially to bring that same experience into the authenticated dashboard.
What we learned
That did not solve the real problem. Users did not want to repeatedly check individual pages themselves.
The actual problem
They wanted an easier and repeatable way to understand how an entire site would appear when shared.
What changed
That insight led to Site Audit, which could inspect a site and produce a broader report automatically. Usage then showed that a report was useful, but users also wanted the information to stay current without repeatedly running the process themselves, which eventually led to monitoring.
Impact
Site Audit created a clearer path from free product usage into the paid platform and became an important example of using behavioral data to turn an existing user need into a new product.
Project: Reducing the time to value in onboarding
Starting point
Originally, the dashboard was treated mostly as a place users arrived after signing up.
Shift
I increasingly pushed the idea that the dashboard itself was part of the product experience. The key realization was that activation depended on getting users to experience the actual value of the product as quickly as possible.
What I worked on
Understanding who the user was, directing different users into appropriate flows, getting developers to a working API experience sooner, reducing unnecessary steps before someone could see the product work, and using experiments and analytics to determine which assumptions were actually correct.
What held up
The faster we could get someone to see the product work, the more likely they were to explore what else it could do. Experiments occasionally disproved my assumptions, which was more valuable than pretending every instinct was correct.
How I make product decisions
I do not simply take feature requests and build them. I combine customer conversations, support issues, feature requests, product usage, marketing behavior, PostHog, GA4, and experiments, then use those signals to identify the underlying problem rather than the requested solution.
A rendering example: when someone says "this page does not load properly," it can initially sound like a fetching problem. But the actual issue might be that the page requires a JavaScript interaction before the desired content appears. That led to functionality allowing users to instruct the renderer to interact with page elements. A customer complaint became an underlying technical problem became a reusable product capability.
Engineering
React · Next.js · TypeScript · Node.js · PostgreSQL · Prisma / Sequelize
My work spans frontend product experiences, backend APIs, database changes, third party integrations, analytics, production debugging, and ongoing modernization of the platform.
Impact
- Expanded OpenGraph from a single core API into a broader developer platform.
- Created new paths from free product usage into paid products.
- Improved activation and onboarding through repeated experimentation.
- Modernized the product experience across the dashboard, marketing site, and developer tools.
What OpenGraph taught me
Ship quickly enough to learn, then be deliberate about what you polish.
Early in my career, I tended to ask: what feature should we build? Now I tend to ask: what does the user actually need?
I also used to think a product needed to be essentially complete before it reached users. Now I get the useful version in front of people, learn what reality tells me, and invest the polish where it actually matters.
Interested in how I approach product engineering?
Get in touch →