Startup Software Architecture - You Never Really Throw It Away: A Conversation with David Gudeman

In the chaotic early days of a startup, the architect's role is less about drawing perfect diagrams and more about navigating ambiguity with limited resources. David Gudeman, co-founder and CTO of VelocityAI, has lived this reality across multiple startups—from building hospital CRM systems to creating interactive edutainment platforms. His experience reveals a core truth: startup architecture is defined by making critical decisions with incomplete information, and the goal isn't to build something perfect, but to build something that can evolve.

Gudeman's path to architecture wasn't planned. With a background in physical chemistry, he moved to Palo Alto, joined a hacker house, and completed a three-month bootcamp. "I was thrown into making a lot of these very challenging technical decisions, it was quite overwhelming at the beginning because I really did not have a lot of experience," he explains. This lack of traditional training shaped his approach: when you're tasked with making important decisions with minimal information, you must get up to speed quickly, make a decision, and live with it.

The Imperfect Information Problem

Startups operate in a state of pronounced deficit across every dimension—market, product, and engineering. "You'll always be at a very pronounced deficit," Gudeman notes. "The reality is that actually is what defines the experience for the most part because you're in that situation across multiple dimensions from the market standpoint, from the product standpoint, from the engineering standpoint."

This uncertainty isn't a bug; it's a feature of innovation. If the information were knowable, large companies would already be doing it. The key is acknowledging this deficit and designing systems that don't bet the farm on any single decision.

At Actium Health, where Gudeman was engineer number one, the company was founded on the premise of "next best action" (NBA) for pop health under Obamacare. This seemed like a solid foundation, but it created problems when real-world needs didn't fit the model. "We were getting into these awkward situations where the problem just didn't fit into the model," he recalls. "It was a mistake to really overly fit the company to this as opposed to having a system that was a little bit more flexible."

The architectural implication was significant. Instead of building everything around NBA primitives, they should have built base primitives that reflected hospital realities, then layered NBA functionality on top when it made sense. This approach would have allowed for evolution rather than excision.

Architecture as Product Strategy

One of Gudeman's key insights is that startup architecture straddles product and engineering. "When I've operated in these startups, a lot of times you are doing a lot of product work. It's not just architecture. It bleeds into architecture because a lot of times the product ideas and how you kind of translate the customer's needs into, 'Well, how are we going to productize this?' heavily determines the architecture."

This dual role became clear when he stepped into a technical product manager position at Actium. He discovered that non-technical stakeholders often speak in solutions, not problems. "With non-technical people, a lot of times the only language they have is solutioning," he explains. "They'll be listening to you. They're like, 'Oh yeah, that is kind of what's going on.'"

The architect must bridge this gap, translating between business requirements and technical constraints. At Tapity, a children's science education platform, Gudeman transformed a system where every episode required handcrafted code into a parameterized graph system. "I worked with the founder to determine like, 'Hey, let's just pick five or six of these and I'll build a system where each episode you can just select the notes and build this graph.'"

This wasn't just technical architecture; it was product architecture. He identified common primitives (single image interaction, two-image selection, polls) and built a platform that eliminated the need for custom code per episode.

The Collaborative Process

Gudeman emphasizes that architecture in startups requires close collaboration between the architect and stakeholders. "The product people should bring the problem, not the solution to the architect. The solution can then be the result of a collaborative discussion."

However, reality often differs. Sales teams, focused on closing deals, may make promises without consulting engineering. Gudeman recalls a situation where a hospital contract included "picnic management for employees"—a feature that didn't align with their core product. "To me, when I looked at the SOW, I was like, 'This is completely insane.' That's my first instinct. But as I've gotten more mature in my career, we should have had a conversation."

The lesson is that architects must be involved early, but also must develop people skills to navigate these situations. "You have to be receptive, you have to be open and you have to be collaborative and create an environment where people feel safe to come explore ideas with you."

Embracing Ambiguity

This leads to a fundamental tension: programming rewards precision, but architecture requires embracing ambiguity. "One of the things you have to be to be a good programmer is being anal-retentive because computers at the end of the day are stupid," Michael Stiefel observes. "They'll do exactly what you told them to do."

Gudeman agrees: "They're unforgiving. And that leads to a mentality which is very good for the engineer, but is not very good for the architect or dealing with product people."

The architect must develop what Gudeman calls "people skills"—the patience to guide stakeholders through Socratic questioning rather than imposing decisions. "You're guiding them for them to agree. You cannot impose these decisions. It has to be consensus driven."

Evolution, Not Excision

Perhaps Gudeman's most important insight is about evolution: "You never know which part you're going to throw away. Certain things you can assume are going to be conserved as the product evolves, like user management, like onboarding stuff."

At VelocityAI, everything initially centered around calls. When they later integrated email, the nested architecture created friction. "I had to do major surgery, and that's really the best you can kind of hope for."

The goal should be surgery, not excision. "If you have to do something, it should be surgery, not excision," Gudeman emphasizes. This means designing systems where you can rearrange components rather than deleting everything.

He warns against the "throwaway" mentality: "I've never seen it work. And if you're in a situation where you've written some very important piece of software as a WordPress plugin, you're in trouble, so don't do that."

Instead, aim for composition using popular technologies. "If you use commonly available popular technologies and you compose them to build a solution," you create more flexibility for future evolution.

Practical Advice for Startup Architects

Gudeman's advice for aspiring startup architects is clear: "Work very closely with them to model the problem before you write any code because code is expensive, cycles spent on the wrong direction are very expensive."

He advocates for front-loading conversations and modeling with pen and paper. "You want to understand beginning to end before you write any code. A lot of times you'll be introduced in the middle without understanding how people review this and how did we get here?"

For error handling—a critical but often overlooked aspect—he recommends a simple pattern: "Anything that is stateful has an error field, an error reason, and you stuff it in there. If anything is stateful and it doesn't have it, you're setting yourself for a problem."

The Zen of Architecture

Despite the challenges, Gudeman finds architecture deeply satisfying. "It really is, for me, modeling the problem thoroughly and having it successfully solve the problem in an elegant way. If you can really achieve that, that's a very, very satisfying outcome."

He sees architecture as an art form with spiritual dimensions. "There is something spiritual about it in the sense that it is an art form and you are expressing yourself and a lot of the decisions are not cut and dry."

The ultimate measure of success? Radio silence. "The best is almost radio silence because it's just working and they're so invested in it, they just assume it should have always been that way."

Key Takeaways

1. Acknowledge uncertainty: Startups operate with imperfect information across all dimensions. Design systems that don't bet everything on any single decision.

2. Straddle product and engineering: Startup architects must understand both technical constraints and business strategy. The product is the architecture.

3. Collaborate early and often: Involve architects from the beginning of product discussions. Use Socratic methods to guide stakeholders rather than imposing solutions.

4. Aim for evolution, not excision: Design for surgery, not deletion. Build systems that can be rearranged as needs change.

5. Model before coding: Spend more time understanding the problem domain than writing code. The best code is often no code.

6. Embrace ambiguity: Develop people skills to navigate the tension between precision (programming) and flexibility (architecture).

7. Instrument simply: When you can't build full analytics, use database forensics and error state tracking to understand production behavior.

The startup architect's role is fundamentally different from enterprise architecture. It's less about perfect diagrams and more about making the best possible decisions with limited information, while building systems that can evolve as the startup discovers what it actually needs to be.

As Gudeman puts it: "You'll never know which part you're going to throw away. But you can design so that you never really throw away working software—you just evolve it."

---

Related Resources:

• VelocityAI - David Gudeman's current venture
• QCon London (March 16-19, 2026) - Where these ideas were originally presented
• Barry Boehm's Spiral Model - Risk-driven software development approach
• Gregor Hohpe's Elevator Architect - Bridging technical and business conversations

Podcast Platforms:

• Apple Podcasts
• YouTube
• Spotify
• SoundCloud
• Overcast
• RSS Feed