Architecting a Startup from Day One: Technical Decisions That Compound

When you start a company today, you’re not just choosing a tech stack, you’re choosing an engineering model.

As CTO of an AI-native startup, I made an explicit decision: AI-assisted engineering would not be an experiment or a productivity tool. It would be the default way we build.

In this session, I’ll walk through the foundational technical decisions that shaped our first months:

- Treating AI workflows as infrastructure, not add-ons
- Structuring work so small teams maintain high context
- Designing documentation that machines can reason about
- Making architectural intent explicit from day one
- Choosing independence over convenience
- Avoiding early complexity that looks “enterprise-ready” but slows momentum

This is not a startup success story. It’s a candid breakdown of the technical principles and trade-offs that shaped how we built and what I would repeat (or change) next time.

Designing Architectures That AI Can Work With

AI-assisted development doesn’t just change how we write code, it exposes how well (or poorly) our systems are structured.

In many teams, AI struggles not because the tools are weak, but because the architecture is unclear: implicit domain knowledge, blurred boundaries, and inconsistent patterns.

Having worked on introducing AI-assisted workflows in a 5,000+ engineer organization and later designing an AI-native engineering setup from scratch, I’ve seen a consistent pattern: AI effectiveness is directly proportional to architectural clarity.

In this session, we’ll explore:
- Why documentation is more important than ever
- Why bounded contexts matter more than ever
- How domain models influence AI output quality
- Making architectural constraints explicit
- Reducing ambiguity in large codebases
- Practical refactoring patterns to increase AI leverage

This talk is for architects who want to design systems that are not only maintainable by humans, but understandable and usable by AI.

Making AI-Assisted Engineering Work in Practice

Many organizations introduce AI coding tools expecting immediate productivity gains, only to discover inconsistent results, architectural friction, quality concerns, and team confusion.

I was part of the core group introducing AI-assisted engineering workflows in a 5,000+ engineer organization, working through adoption challenges, governance questions, and architectural constraints at scale. I later built an AI-native engineering setup from day one in a startup environment.

In this session, I’ll share the practical lessons learned from both environments:

- Why unclear architecture kills AI leverage
- What needs to change in codebase structure
- How team practices must evolve
- The common mistakes that create AI chaos instead of acceleration

At the end of the talk you will have a clear, actionable items that you can start embedding into your teams right away

This talk is a field guide for architects, engineering managers, and CTOs who want to introduce AI into their engineering organization and actually benefit from it.