Elias Puurunen

The World's First Full-Stack Event Producer.

Author of Memorable, Profitable, Virtual

Get the book 👇

[Uncle Bob Martin @unclebobmartin]

It is hard to imagine an idea more brain dead than a moratorium on data centers.

[Elias Puurunen @agfinn]

@shauseth Meatslop

[Elias Puurunen @agfinn]

@spinelessaisha Making a virtual memory manager in my OS class was hard af but also one of the most rewarding experiences when it worked.

[Elias Puurunen @agfinn]

Remember when a stock Windows install could be made to fit under 40MB and still be useful?

[Dave W Plummer @davepl1968]

In my reading of the ancient book of @joebelfiore, I assume the Start menu was in the bottom-left because it made for a convenient mouse anchor. I'm not sure who else could confirm that - @bradsilverberg maybe?

By that I mean that if you drag the mouse down and left far enough, it is, by definition, now ON the Start button. So it's as simple as swipe-and-click, no aiming.

That's not true once you start centering things.

Centering makes sense to me on a touch interface, but not on a mouse-based system.

[Elias Puurunen @agfinn]

Not to mention hybrid opens up attendance to entire audience segments that can't make it to your event.

We've had feedback surveys from new parents, those with disabilities, and those recovering from major illness/surgery that thank organizers for doing hybrid.

[Julius Solaris @tojulius]

Keep an eye on hybrid, because flights and hotels keep getting more expensive and part of the audience will do the math and stay home. Events with a ready virtual option keep people whose travel budget won't stretch.

Of course, if your content sucks, hybrid will never work for you.

[Elias Puurunen @agfinn]

Don't forget we also gave the world:
- the entire concept of a telephone
- modern smartphones (Blackberry)
- telecom and internet infrastructure (Nortel)

This country should have a GDP that eclipses almost every other nation on earth.

We need to fix why we're so bad at capturing and compounding the value we create.

[Elias Puurunen @agfinn]

Now is the time for Canada to become the world's data center.

[Elias Puurunen @agfinn]

@tojulius Why doesn't every major event have seating everywhere?

Sitting in a corner on the floor huddled next to a power outlet, feeling like I'm waiting to be rescued by FEMA despite spending thousands of dollars to be there

[Elias Puurunen @agfinn]

@JoshuaLisec Nah make your own with RFID badges and a Raspberry Pi.

[Elias Puurunen @agfinn]

@audrlo It's the prerequisite for robotics.

It's also going to have the same class of impact that the smartphone had - entire swaths of products replaceable by robotics and AI.

[Elias Puurunen @agfinn]

@roguewealth In the early days of Twitter we didn't have fancy graphs, we just had the Failwhale.

[Elias Puurunen @agfinn]

The worst feeling in the world is going to take a sip of coffee but the mug is empty

[Elias Puurunen @agfinn]

@tojulius You can't, we need you

[Elias Puurunen @agfinn]

@davepl1968 @Lertulo I'd love to see the source code for ScanDisk. Always love seeing what makes those old programs work.

That said... If it was written in asm... I'll need to get out a decompiler.

[Elias Puurunen @agfinn]

Hoping @tojulius approves of the X algo rn

[Elias Puurunen @agfinn]

You need people in different ways.

The more we use AI, the more I realize we don't need people doing crap busywork/manual integrations.

But the whole production side? Never had a moment where I've said, "this would be easier with fewer people."

You'll also need people to supervise AI too.

That said... maybe I haven't had enough coffee yet but the path for entry-level people still seems fuzzy.

[Elias Puurunen @agfinn]

@bzogrammer Is it even possible to run a modern CPU in a mode that bypasses speculation/cache?

[Elias Puurunen @agfinn]

I love me a Timex Ironman but ngl I'm liking this Casio.

[Elias Puurunen @agfinn]

@roguewealth I mean the ANSI C book is amazing, but I'm also biased because I've come to adore C.

[Elias Puurunen @agfinn]

Coding a SaaS Was Never the Expensive Part.

If you've got a service-based business and you're tempted to create a software product or SaaS, read this before spending five to six-figures on a Minimum Viable Product.

The most expensive part of writing software was never the code itself.

Before I tell you the most expensive part, let me ensure my credentials are in good order.

My degree is in Computer Science. I've been writing code in a professional capacity since 2007. I'm coming up on twenty years of coding, and I've been an event and AV nerd even longer.

I've developed, marketed, and sold my own software. I've audited code written by outside consultants. I've been the VP responsible for bringing on developers to complete a project. I've started and shut down SaaS products.

And I've been in that unenviable position of wanting to turn my service-based business into a software-based business.

If you're running a service-based business, the allure of your own SaaS is powerful.

Predictable, recurring revenue.

Customers help themselves.

It's an asset that you might sell one day.

If you've been in your industry long enough, one day you might spot a gap in the market. A problem that could be solved with a SaaS.

In the excitement, you'll do some research and discover that nobody else seems to be working on it.

You might even get a quote to build an MVP from a consultant that makes your breath hitch... but not enough to say no.

You might even think, "that's not as bad as I thought it would be."

Let's pump the brakes.

Coding isn't expensive. It never was.

Take it from me, someone who spent an uncomfortable amount of money developing an event tech platform, only to find out after most of the way through the "MVP" that I'd built the wrong thing.

It's not the coding that's expensive. The changes are.

The later those changes creep into the process, the more expensive they become to fix.

Changes burn budgets. Along with hosting (cloud isn't free), compliance (SOC 2 and GDPR, anyone?), bug fixes (it might work on Chrome, but it's glitched on Safari), insurance, backups, marketing... I can go on.

After you've spent time, energy, and money on a project, sunk cost fallacy comes for you. You spend revenue from your service business on building and changing your SaaS.

All of a sudden you're not just burning the candle at both ends. You've got a lighter held up to the middle of the candle in an attempt to get that going too.

"So I shouldn't build a SaaS for my business?"

Not quite. But I would do it a bit different.

Before handing five or six figures to a consultant, I would use AI to prototype and test the idea.

But before we ask AI to write a line of code, we need to back up a few steps.

I've talked to many founders who have this mental model when it comes to building a SaaS:

Identify market gap.

Build minimum viable product.

Onboard tons of customers and achieve hockey-stick growth.

Sell to Meta, Google, Microsoft, or some other player in 3-5 years.

Profit.

The math of building a product is very different from running a service.

AI is reducing development costs and timelines. A new SaaS does not have 3-5 years to onboard customers, build a moat, and hockey-stick their way to an exit.

The old SaaS playbook and many of the promises contained inside should be moved to the History section.

When you offer a service, you have clients whom you work with. You're doing something valuable and logistically intense (h/t to Daniel Fazio for that term) for them. Revenue per client is high, margins are good. The relationships themselves become valuable come exit time.

When you offer a product, you have customers. They're expected to do the work. And they're not guaranteed to stick around either. Revenue per customer is low. Your margins will rely on volume.

It might not show up as a neat line on your financial statements, but add enough support requests, infrastructure usage, refunds, onboarding problems and feature demands, and some customers will cost more to retain than they pay you.

And that's assuming your SaaS actually solves the true core problem you identified in the first place. Because in my experience, the chances of getting that 100% right the first time are almost zero, even if you're writing software for yourself.

You will also encounter "potential customers," also known as prospects, who will lie to you.

Some of their greatest hits include:

"Oh yeah, once your product has Feature X, then we'll buy it."

"This is really valuable and solves (my big problem), but it's too expensive."

"We just need this small change..."

I ran into this when I was VP of Support for a startup. I would meet directly with customers and prospects to see how they used our SaaS, and would ask about missing features. I can't remember a case where we shipped a "Feature X" ask from a prospect and they then bought a subscription.

Sidebar: this doesn't mean build blindly and never talk to customers. But you should always put at minimum 10x the weight of feedback on a paying customer, not prospects. Prospects are window-shoppers. Customers are invested.

If you interview 100 prospects and they all say your product is missing Feature X, it may be missing Feature X. But always value the opinions of paying customers first. One paying customer's feedback is worth 100 prospect opinions or more.

A prospect's request is a hypothesis. A customer's request is evidence.

So if you are thinking of building a SaaS, I'd do it a bit different. I'd skip hiring the consultants to build an MVP. With AI and some user interface sketches on paper, you can build a prototype or internal MVP for a fraction of the time it used to take.

Then, use your MVP to help deliver your services.

You'll discover which workflows break down, which assumptions were wrong and what needs to change.

This is the biggest win for AI coding, by the way. The changes used to be the expensive part, because it meant potentially winding back or throwing out weeks, months, or even years of development effort. AI makes experimentation much cheaper.

When I was studying Human-Computer Interaction, we were always told to show customers low-fidelity prototypes first. The more polished and refined the product we presented, the less likely we were to get true, actionable feedback. People don't mind torching ideas when they're on a piece of paper.

As you use your software to deliver your core service better than your competitors, you'll start developing strong opinions about how the work should be done.

Then you can make honest decisions about:

Should we even make this SaaS available to our competitors, or keep it as our own Secret Sauce?

Is this a big enough problem to warrant turning into a separate product that we feed and maintain?

Will this product be self-sustaining?

This is how we use our SaaS and software to strengthen our core services at Tractus.

I wrote Multiview for NDI not because I spotted a gap in the market. I wrote it because I was tired of opening multiple Studio Monitor instances to control my cameras and monitor my NDI sources. Over time, it turned out others had the same problems to solve that I did.

If I put on my sales-funnel hat, our NDI utilities are part of the funnel for our broader business. Multiview and our other tools have led directly to consulting projects.

Sidebar 2: I didn't wake up one day with this plan. This is the result of Doing Things the Hard Way for a long time, then putting the pieces together and thinking things through.

We do this with our event and reg platforms too, but the difference is we don't sell any access to those.

They're ours. And we do this on purpose.

We use them to organize and deliver webinars and hybrid events for clients. At one point, we did sell access. We eventually found that the support burden and constant change requests pulled too much attention away from our core business.

The software was more valuable when it strengthened our service than when we tried to turn it into a standalone SaaS.

Some of our software we sell. Some we keep for ourselves.

Both strengthen our core business.

AI has slashed the cost of writing software and SaaS tools... and it's also slashed the cost of making changes. A technically experienced founder can now turn an idea and some sketches into a working prototype far faster than before. And even when outside technical help is still required, the business can test far more assumptions before committing to a massive development project.

But cheaper code does not automatically create a viable SaaS.

I don't believe the winners will be the people who build a product, aim for 1% of a billion-dollar market and hope for an acquisition by a FAANG company or private equity firm within three to five years.

Soon, everyone will be able to build software. And I do mean everyone.

The winners will be the businesses who use their own software to deliver an exceptional service to real clients, refine it through real-world use and only then decide whether it deserves to be sold to the world.