PurpleOwl 2025: The Year We Stopped Just Building Software

January 1, 2026
9 min read
Alex Radulovic

In 2025, PurpleOwl learned the power of building software *with* users, not just *for* them. Discover how AI, component architecture, and a focus on real-world workflows transformed their approach. Learn about Parliament and DataLens!

PurpleOwl 2025: The Year We Stopped Just Building Software

PurpleOwl 2025: The Year We Stopped Just Building Software

Every year teaches you something. Some years it's patience. Some years it's humility. 2025 taught us that the line between building software for people and building software with them is thinner than we thought — and that crossing it changes everything.

Image 2

Here's what happened.

We Built a Product

For most of our history, PurpleOwl has been a studio. You come to us with a problem, we build you a solution. Six to ten weeks, not eighteen months, because our 200+ component library means we're assembling tested building blocks rather than starting from scratch every time. That model works. It still works. But this year we did something we hadn't done before: we built something for a market, not just a client.

It's called Parliament.

The name comes from what you call a group of owls — fitting, since it's software for peer advisory groups. Think facilitators managing CEO peer groups, or running paid masterminds. These are people whose entire job is bringing leaders together, and they were cobbling it together with Slack threads, shared docs, and spreadsheets. Sound familiar? It's the exact same pattern we see in every industry we serve: smart people doing sophisticated work with tools that weren't built for how they actually operate.

Image 3

Parliament launched with three editions — Forum, Mastermind, and Council — all running on a single codebase with flavor-based configuration. One architecture, different terminology and feature sets per market. We presented it to peer group facilitators for feedback, built a steering group of actual users, and started iterating based on real usage. The price point is intentionally accessible: $29-49 a month per group. We're not trying to extract maximum revenue. We're trying to prove the platform.

Because here's the real play: Parliament isn't the product. Parliament is what the product can do.

What we're really building is a repeatable way to turn messy, human operations into software that fits — fast. Parliament is the proof that our platform can ship a coherent vertical product without losing configurability. If we can do it for peer groups, we can do it for any domain where coordination is the job. In 2026, you'll see us take this pattern into adjacent markets where "spreadsheets + Slack" is still the operating system.

The Moment It Clicked

The moment it clicked wasn't a feature shipped — it was a sentence. A facilitator in our steering group said, "I don't need more software. I need fewer follow-ups." That changed our roadmap instantly. We stopped optimizing for capability and started optimizing for closure: fewer loose ends, fewer tabs, fewer "who's doing what?" moments. Parliament didn't become smarter. It became calmer.

Image 5

That's the difference between building for people and building with them. When you're building for them, you imagine what they need. When you're building with them, they tell you — and it's never what you imagined.

We Doubled Down on AI — But Not the Way You Think

Everyone in software is talking about AI. Most of them are bolting a chatbot onto their existing interface and calling it innovation. We went a different direction.

We built DataLens, a data analysis tool designed specifically for how small businesses actually work. Not for data teams with SQL skills and clean datasets — for the owner who has exports from six different systems, a folder of PDFs, and fifteen minutes between crises. Drop your files in, ask a question in plain English, get an answer. The technical breakthrough is treating everything — spreadsheet rows, product photos, phone call transcripts — as vectors that can be searched and clustered together. A photo of a product and a sales record for that product can now "know" they're related.

Image 6

But the AI work I'm most excited about is our requirements gathering system. We designed a conversational AI that conducts discovery interviews with business owners — the same "follow the money through the company" methodology I've used for decades, but orchestrated by an AI that maintains state across multiple sessions, fills information buckets through natural conversation rather than linear questionnaires, and outputs schema definitions ready for our platform. It uses a non-linear, bucket-filling approach where the AI gently steers toward gaps without making the conversation feel like an interrogation. The user sees a visual progress indicator showing where they are in the process, without being overwhelmed by technical complexity.

This is what I mean when I say code should adapt to people, not the other way around. The AI doesn't ask the user to think like an engineer. It meets them where they are.

Our AI Line in the Sand

We treat AI as an interface and an assistant — not an authority. Anything that impacts money, compliance, or customer commitments has to be inspectable: sources attached, assumptions explicit, and a human-confirm step where it matters. We design for confidence, not vibes. The system should either show its work or admit what it can't know yet.

We also assume clients care about privacy more than novelty. We built with least-privilege access, clear data retention rules, and the ability to separate company memory from model behavior. If your data goes in, you need to know exactly what comes out and where it lives.

The Platform Grew Up

Under the hood, our platform had a significant year. The AI-driven application layer now includes intelligent assistants that analyze transactional data to suggest process optimizations, forecast demand, and recommend inventory replenishment. Natural language engines categorize documents, generate reports, and summarize meetings. We built sales training simulations that role-play realistic prospect interactions with natural skepticism and adaptive pacing.

Image 4

The core architecture — GraphQL-backed API, drag-and-drop trigger builder, SAML-based SSO, barcode and QR scanning for warehouse operations — continued to mature. Every piece is still modular, still configurable, still designed so that adding a new workflow means adding components rather than rewriting the foundation.

We also rebuilt purpleowl.io with a modern component-based frontend, invested heavily in our blog content, and created internal tooling for our content team — including a custom article management system where each piece lives in its own directory with metadata, markdown, and images. No database, no CMS overhead. Just files that work.

We Served Businesses That Nobody Else Would

Our client work this year spanned engineering firms, manufacturing operations, healthcare practices, MSPs, senior living platforms, nonprofits, and more. The common thread wasn't industry — it was frustration. Every one of these businesses had been told to either use generic tools or pay enterprise prices for something that actually fits.

One highlight: we continued our work with Purple Door Finders, the "Zillow for seniors" that Christina Bremner built with us. Over 60,000 communities partnered. A subscription model that disrupts an industry built on exploitative referral fees. Christina named her company as a tribute to PurpleOwl, which still means a lot.

Image 1

We also developed comprehensive sales training programs for MSPs, created presentations for peer advisory groups, and worked with clients across sectors that reinforced what we already knew: small businesses have complex operations, unique workflows, and specific compliance needs. They just don't have Fortune 500 budgets.

What We Got Wrong First

If you're only reading the highlights, you're getting the edited version. Here's the unedited part.

We underestimated how emotional data cleanup is. When we asked small business owners to drop files into DataLens, the mess wasn't technical — it was historical. Years of decisions, compromises, and personnel changes baked into inconsistent spreadsheets. Treating it as a data problem missed the point. It's a trust problem. People needed to know the tool wouldn't judge the mess before they'd let it see the mess.

"Ask in English" works until the business asks a question their systems can't actually answer. We had to teach DataLens to say "I don't know yet — here's what's missing" without feeling useless. That turned out to be a harder design problem than making it smart in the first place.

Steering groups don't just validate — they contradict. Early on, we treated disagreement among facilitators as noise. It took a few sessions to realize that contradiction is the product signal. When two facilitators want opposite things, you're looking at a configuration axis, not a feature request.

And we learned the difference between automation and relief. Some workflows shouldn't be faster. They should be less present. A facilitator doesn't want faster follow-up reminders — they want follow-ups that resolve themselves. That distinction reshaped how we think about every feature.

How We Changed Internally

Our theme was building with people. That meant we had to change how we operate, not just what we ship.

We moved discovery from a phase to a loop: ship, observe, interview, tighten. Requirements stopped being documents and started being testable decisions. We designed features around time-to-first-value, not feature completeness — if a user can't feel the benefit in the first session, we haven't shipped yet.

And we started treating our component architecture as a product constraint, not just an engineering preference. Every new module has to prove it's reusable before it earns a spot in the library. That discipline is what lets us move fast without accumulating debt.

What 2025 Really Taught Us

The lesson of 2025 is that the gap between "affordable" and "actually fits your business" is closing faster than anyone expected. AI is a big part of that. Component architecture is a big part of that. But the real accelerant is a shift in expectations. Business owners are done accepting workarounds as normal. They're done believing that software has to be painful because that's just how it is.

Every company, regardless of size, should be able to have software that respects how they operate. Software that makes their work easier rather than harder. And in 2025, we proved — to ourselves and to the businesses we serve — that you shouldn't have to wait a year or spend a fortune to make that happen.

Parliament exists because facilitators trusted us with their real workflows, not their idealized ones. Same with the owners who dropped messy exports into DataLens and told us, bluntly, when the answers weren't good enough. If 2025 was the year we crossed into building with people, it's because people met us there.

Here's to what we build next.

— Alex Radulovic, Founder & CEO, PurpleOwl

Keywords

software developmentAIcomponent architecturesmall business softwareuser feedbackSaaSDataLensParliament

Related Articles