Our ARR grew 13x in the last 12 months, and we did it with a deliberately small team. Now we're looking for an ambitious software engineer to join us as we start to scale up. We don't care much about credentials; we care about what you can build, how fast you learn, and how you collaborate. Adam and I started Evidence because we were frustrated with the state of BI tools. We hated using them, and while code was automating other parts of our work, BI was still stuck in proprietary drag-and-drop interfaces. So we built an entirely code-based alternative and launched it as an open source project. Today, Evidence is used by thousands of organizations around the world, including Fortune 500 companies, global investment managers, and national governments. And increasingly, it’s what AI coding agents reach for when they need to build analytics. Our commercial product, Evidence Studio - which includes SSO, access control, AI agents, email schedules, Slackbot, and a ton more - is growing rapidly. We're seeing more companies replace tools like Tableau and Power BI with Evidence. But our ambition has always been much larger than building another BI tool. Our goal is to reshape how organizations work with data and communicate what they know, and AI is opening up an entirely new opportunity to do that. Our next phase is all about AI. We want to help data teams build self-driving analytics systems for their organizations - systems that proactively surface insights and improve themselves, while giving anyone the freedom to explore data, get answers, and create. We're building the context, tools, and feedback loops that let AI do real data work in a reliable, governed way. Given our small team, the people who join us have an outsized impact. You'll work directly with customers and the founders, make major product and technical decisions, and help shape where Evidence goes next. We're looking for someone who loves solving open-ended problems and cares deeply about product quality. If that sounds like you, DM me. And if someone great comes to mind, I'd love an introduction.

Data work is behind software engineering in AI adoption - but not for long. In my recent talk at AI Council, I explored what BI looks like in a world where AI is exceptionally capable (video in comments). The most interesting AI systems in software today are built around closed feedback loops: agents observe usage, make changes, validate outcomes, and improve over time. The same pattern is coming to analytics. The key prerequisite is treating analytics as code. When reports and analysis are defined in code, agents can read, write, review, and improve them just like software. That's how we'll move from AI-assisted workflows to systems that continuously improve themselves.

A sneak peek of our upcoming Insights feature in Evidence. Have an agent build an ad hoc analysis for you, then save it and share it with your team. The agent has context from all your reports, so it can reuse definitions and visualizations. Or it can point you to a report that already answers your question. Each Insight is saved with the original prompt and any methodology that went into creating the work, making it auditable and reusable.

AI + BI is great. But AI + BI + CI is where things get really interesting. Here’s what that looks like in practice. You start with a Linear issue. You assign an agent. It generates an Evidence report, opens a pull request, and sends you a link. The code is simple and readable. It’s just markdown. You can scan it and immediately understand what’s happening. The Evidence GitHub bot runs validation tests and adds a preview link so you can see the report before it goes live. You can merge with full confidence that nothing has broken. This is the CI portion that most AI platforms are missing. It means you get you the speed of vibe code-able reporting, but with the governance and reliability of production software.

With usage analytics data in Evidence, it's becoming possible to automate the full reporting lifecycle. Today you can build a report to recommend actions based on user data. The next step is plugging in AI to proactively recommend actions for you. That's where we're heading and it's getting very exciting.

Love getting messages like this. We consider customer feedback to be an extension of our product experience. The faster we can fix issues, the more delightful the experience of working with us. It's an unbeatable feeling to see it working for customers.

Most product bugs don't get reported. They're just small enough that customers work around them and move on. We built our AI assistant to flag these automatically. It sits in customer workflows, sees where things break down, and opens issues for us without anyone asking. Yesterday I started my morning reviewing problems it had surfaced overnight. Nothing dramatic - confusing flows, missing docs, edge cases. The kind of stuff that individually doesn't matter but collectively degrades the experience. We fixed them same-day and looped in the affected customers. This feedback loop is working well enough for our team that we're now building ways for our customers to create similar loops with the data products they build in Evidence.

AI can easily handle tedious but necessary work - like keeping analytics well documented. In Evidence, our AI assistant can join data from multiple sources, calculate metrics like conversion rates, and document the logic as it goes. Since Evidence already has strong documentation features built in, that context sticks around instead of living in someone’s head or a random notebook. The result is faster answers with clearer reasoning. Feels like a glimpse into how data teams will work in the future. To build this table, we gave the AI assistant 10 mock datasets and asked it to create a conversion funnel. It identified the right tables, columns, and filters automatically, and included definitions directly in the column headers.

Dense tables are sometimes overlooked in favour of charts, but they’re often the fastest way to understand complex data. We put a lot of effort into making our tables feel publication-quality and easy to scan. One small but high-impact thing we just shipped is column groups. You can now group related columns under a shared header (like Revenue or Volume in this example), which makes wide tables much easier to read at a glance. Adding a column to a group is intentionally simple and doesn’t require any extra layout work. It’s a small feature, but it makes dense data feel way more approachable when you’re actually reading it.

We’ve been working on a cleaner way to make reports interactive, and added variables you can insert anywhere in @evidence_dev. Inputs like sliders or dropdowns generate a variable you can reference in SQL, charts, or even plain markdown. Change an input, and anything using that variable updates instantly. You can parameterize almost anything - including number formats and table/column references

We recently had a sales call with a Fortune 500 company, expecting to give them an intro to Evidence and BI-as-code. Instead, they told us they’ve been using our open source software - and loving it - for years. They even made a few modifications and created a patch to solve an issue they ran into. This kind of thing happens from time to time, and it’s always a small thrill - one of the fun surprises of maintaining a widely used open source project.

A week ago, we rebuilt our AI assistant from the ground up, and the results so far have been pretty amazing. From a customer: “Massive upgrade. I recommend all Evidence devs try it out for edits now.” What changed: - A new Evidence docs MCP - Claude Opus 4.5 as the primary model under the hood - Deep project awareness, so it can: - Query and analyze your data - Summarize what it sees on the page - Write Evidence markdown and SQL - Update page and project settings directly from chat (incl. themes) - Send feature requests and bug reports to the Evidence team Next up: - Validation and feedback loops to keep pushing the success rate higher - A CLI that lets you use your own AI model to work on Evidence Studio reports The end goal: vibe-coding reports that are validated, governed, and production-ready - all inside Evidence.

A few years ago, if we shipped a bug, we might not hear about it for days. Now we hear about issues almost immediately - because customers rely on us for critical workflows. Friday was a good example. A few customers reported an urgent issue, so we jumped on it, spent several hours investigating, shipped a fix the same night, and notified them as soon as it was live. It reminded me of my time doing data work: you usually only hear about problems quickly when what you’ve built is being used. The most valuable reports are the ones people rely on to make decisions. Even though something breaking is never a good feeling, hearing about it immediately is often the clearest sign that people truly depend on what you’re building.

Most BI and analytics tools struggle with something I think about a lot: use case frequency. They give you tons of controls, but it’s hard to make even basic dashboards that look good and perform well. Often because the tools treat every possible action as equally important. In reality, reporting isn’t evenly distributed. Something like 90% of reports are built from the same small set of ingredients. It’s easy to assign the wrong weight to features when the people building the product haven’t spent much time building reports themselves. Without that experience, it’s hard to know what’s common, what’s rare, or what the default behaviour should be. At Evidence, the product is built by a team of ex-analysts and data leaders, and we actively use Evidence ourselves. That gives us strong opinions about the right user experience, and a shared understanding of which patterns show up constantly versus occasionally. We bake that directly into our product development process. When we discuss feature ideas internally, we’ll say things like "this is a 95% use case" or "this is a 2% use case". That framing drives a lot: - How much priority it gets - Whether it becomes a default or an advanced option - How much surface area it earns in the product and in docs High-frequency use cases become obvious and opinionated. Low-frequency ones stay possible, but intentionally out of the way. The goal is that by default, anyone using Evidence can produce the same outputs a top-tier analyst would - because the right choices and trade-offs are already baked into the product. We get there by designing explicitly around use case frequency.

We're getting ready to release some major updates to our maps in Evidence Studio. I can't wait to share, so I'm just going to post some examples this week so you can see what we've built. First up we've got a point map including a size scale and customizable shape. Code for this example in the comments

We're only 2 days into 2026 and already have a TON of new things ready to release to Evidence customers - including new options for maps, charts, tables, user management, data connections, and more. Moving this fast is one of the best parts of building Evidence. I still remember using other BI tools and checking on decade-old feature requests, hoping they’d eventually ship. We’re deliberately building the opposite experience: staying close to customers and turning feedback into real product changes almost immediately. At this pace, the product is evolving quickly. It's going to be a big year - excited to start sharing updates next week

Shipping some early Christmas gifts to @evidence_dev customers this week - like this map that lets you zoom in to see more granular areas