Thinking

What Twenty Years of Painting Taught Me About Building Technology

I.2 a.m.

It is 2 a.m. The studio is quiet. The painting on the easel has thirteen invisible layers of cold wax under it, and is about to receive its first visible brushstroke. I have one chance at this mark. There is no undo. There is no save. Whatever I lay down, the painting keeps.

I have made the same kind of decision at the same hour in front of a different surface, with a keyboard instead of a brush. The medium changed. The decision didn't.

Here is the thesis: twenty years of abstract painting trained one specific muscle, and that muscle, more than any technical skill I picked up along the way, is what lets me build software the rest of the dealer-tech industry hasn't built. The painting wasn't the credential. The painting was the gym.

What follows is the proof.

II.What an oil-and-cold-wax painting actually is

When I describe my paintings to most people, they nod politely. So let me describe the actual process, in the actual order, because the process is where the lesson lives.

I start by staining and bleaching a Baltic birch panel. Then I apply a clear gesso to seal and protect the surface — the ground that everything else will sit on. From there, I apply ten to twelve transparent layers of cold wax mixture or transparent oil paint, each one shifting the depth and tonality underneath without obscuring it. Then I wait several months for that ground to fully dry.

Only then do I begin painting in the way most people imagine painting — brushstrokes, hand on the panel, intention with every mark. Between fifteen hundred and twenty-five hundred individual brushstrokes per piece, with different sized brushes, each one fully visible in the finished work.

And here is the part that matters: the process is purely additive. I don't remove. I don't erase. I don't paint over. Every mark I lay down stays. Which means every mark has to be fully intentional, the first time, every time.

There is no Cmd-Z in my studio. There is only what's already on the panel and what comes next.

That single constraint shaped twenty years of my practice. It also, eventually, shaped how I build software.

III.Layers are just another word for meaning

Layering is the throughline of both practices. The temptation, when I describe it, is to let "layering" become a fluffy metaphor — depth, complexity, richness. I want to be more precise than that.

A layer, in the studio, is meaning. We are applying meaning on top of meaning. But the discipline of layering is not the addition. The discipline is the restraint. We add only the essential layers. Nothing more. The piece works because of what is on the panel and what was deliberately kept off it.

Diablo is built the same way. Every feature, every agent, every workflow is a layer of meaning we have applied to the dealer's day. And every layer that didn't make it in — the ones we cut, the ones we said no to, the ones competitors shipped and we deliberately didn't — is part of why the platform feels coherent instead of overstuffed.

Most software fails at the second discipline. Builders keep adding. The layers stop having meaning, and the product becomes the kind of dashboard that takes a training manual to operate. Coherence requires subtraction, and subtraction requires knowing what the meaning is in the first place.

IV.Trust the gut. Use the brain.

A six-month painting cannot be all intuition and cannot be all process. You learn early that you need both, and you learn what each one is for.

The brain builds the process. Process is where knowledge lives, where vision is committed to a plan, where strategy gets battle-tested into something repeatable. Process is the architecture — the order of stages, the materials, the constraints, the ground rules I just described.

Intuition is the guide inside that architecture. Every step along the way, the painting confronts you with options the plan didn't anticipate. Which mark, where, how heavy, what color underneath, how long to wait before the next pass. The plan can't make those decisions. Only your eye can.

The mistake junior artists make is thinking it's intuition versus process. It isn't. It's intuition inside process. The process tells you what's allowed; the intuition tells you what's right.

I build software the same way. The architecture of Diablo is intentional, planned, and battle-tested. But every individual call — what to ship, what to cut, what's done, what needs another pass — is an intuitive decision made inside that architecture. Anyone who has tried to build a serious system with only one or only the other will recognize what I'm describing.

V.Thousands of marks nobody sees

A finished painting reads as a single image. A dealer's experience of Diablo reads as a single product. In both cases, what you actually see is the surface — and the surface is the smallest part of what's there.

Beneath the visible brushstrokes are the ten to twelve layers of ground that took months to lay and longer to dry. Every visible mark sits on top of that invisible structure. Without it, the painting falls apart. With it, the painting holds.

The same is true of software. The user sees the interface. The user sees the message that came back in three seconds, the dashboard that loaded the right number, the lead that got followed up before the dealer noticed. What the user does not see is the error handling, the retries, the edge cases, the integrations, the database design, the agent behavior under load — the underpainting that makes the surface feel inevitable.

The brushstrokes are simultaneously the complete idea and the entire process. They are the thing the viewer sees and the thing the work is made of. Take either away and there is nothing left.

Most products fail because they treat the underpainting as optional. They ship a polished surface on top of a half-built ground. It looks fine in a demo. It collapses in production.

VI.Knowing when the conversation ends

The hardest skill to teach a young painter is knowing when the painting is done.

There is no checklist. The signal is patience and listening. You respond to the artwork. The artwork responds back. A painting tells you when it is finished — not by getting better, but by going quiet. The conversation stops. There is nothing more to say that hasn't already been said. The next mark would be repeating yourself.

Software has the same signal, and most engineers can't read it. Most engineers ship too early — the conversation hasn't started yet, but they're tired of building. A few ship too late — the conversation ended weeks ago and they're still adding marks because they can't tell.

I have made both mistakes. The painting practice taught me to catch the second one. When I notice I'm tuning something that already works — moving a button by two pixels for the third time, rewriting a function that's already shipping — that's the painting telling me the conversation is over. Stop. Ship. Move on.

VII.The first time the two practices became the same thing

I grew up around software. My father was a pioneer in the early days of the industry, and I was building on computers from the time most kids were learning to ride bikes. So the two disciplines were never strangers to me.

But the first time I felt them collapse into the same practice was in 2021, with a project I called Rebirth.

I extracted every layer from every painting I had ever made. Every brushstroke. Every mark. I digitized them into a program. The program then generated new original digital artworks from those building blocks — works that replicated and evolved and transformed over time. The same painting practice, now operating at a speed and scale a single human couldn't match.

That was the moment. Not because the digital art was important — it was a side project, a thing I made for myself — but because building it required me to write down the exact rules of how I had been painting for twenty years. And when I wrote them down, I realized I had been writing software the entire time, in oil and wax, on Baltic birch panels.

Every decision I have made in building Diablo has been a version of that realization. The principles are the same. Only the medium changed.

VIII.Value from nothing

Making a living as an abstract artist is statistically one of the hardest things a person can attempt. You are not selling a service someone needs. You are not solving a problem someone has. You are creating value where there was no demand, and convincing people who weren't asking for your work that it belongs in their lives.

That practice — value from nothing — is the single most useful muscle I have brought into building companies.

Most software founders are in the inverse position. There is a known problem. There is a market. There is competing software they can benchmark against. Their job is execution within a known frame.

I have spent twenty years making things people did not know they wanted. The discipline of doing that, repeatedly, against the lowest-odds career path I could have chosen, taught me one thing more clearly than anything else: with the right plan, the right execution, and an honest amount of resilience, almost any specific outcome is achievable. You can have anything in this world. You cannot have everything. Choosing the few things is the entire game.

I do not believe that because I am special. I believe it because I lived through twenty years of evidence that it is true.

IX.Why this matters

So let me close where I started.

This is not an essay about my art career. It is about the muscle that career trained — the ability to think abstractly. To build something out of nothing. To recognize a system where most people see only its parts. To know when a thing is done. To trust intuition inside the architecture of a process.

That muscle is what lets me build software the rest of the dealer-tech industry hasn't built. Not the design background. Not the engineering. The abstract thinking. The years of staring at a blank Baltic birch panel and finding the painting that wasn't there yet.

A finished Diablo platform looks, from the outside, like a software product. But the practice of building it — the layering, the restraint, the patience, the conversation with the work — is exactly the practice that produced every painting that hangs in a collector's home or on a gallery wall.

The medium changed. The discipline didn't.

Twenty years of painting didn't teach me to build software. It taught me to think abstractly — and that, in the end, is the only thing that lets you build software no one else has built.

Author's note: I'm the founder of Ignition Labs, parent of Dealer Ignition and Diablo AI. I'm also a working abstract painter — those works can be seen on the founder page or in full at stevebaylis.com. This essay argues that the two practices are the same practice, which is — I'll grant — exactly what a founder with both backgrounds would want you to believe. If the analogy holds for you, it stands on its own; if not, the natural skepticism toward founders writing about themselves is exactly the right instinct to bring to it.

Keep reading

More essays on AI, automotive, and the work of building companies.

Back to Thinking