Martin Tahli

AI-native

Product &
Systems Engineer

I design and build intelligent products, agentic systems, and software architectures — combining engineering, product thinking, automation, and human-centered design.

View Work Contact

Engineering depth.
A human perspective.

A systems perspective
Ideas → Systems → People → ImpactProblems and constraints shape a product and its architecture. People use the system. Evidence from that use feeds back into the next decision.IDEASSYSTEMSPEOPLEIMPACTEVIDENCE INFORMS THE NEXT DECISION
  1. 01
    IdeasProblems and constraints
  2. 02
    SystemsProduct and architecture
  3. 03
    PeopleBehavior and usability
  4. 04
    ImpactEvidence and feedback
People are part of the architecture. Feedback closes the loop.

Selected work

The problem, the architecture, and the decisions behind the build.

All work
Findavia's Bulgarian discovery interface with service and city search fields.
Public discovery screen · captured 23 September 2026 · cropped.
LivePrivate source

Findavia

One service marketplace for finding a provider, booking real availability, and coordinating the work.

Primary product engineer

  • Flutter / Dart
  • Supabase
  • Playwright
  • GitHub Actions
View case study : Findavia
Live product ↗
Diagram of Treasury's financial data flow from Trading 212, Interactive Brokers, and manual assets through normalization and reconciliation to the wealth model and bounded AI interface.
System map · based on the reviewed 19 September 2026 implementation snapshot.
LivePrivate source

Treasury

A private wealth operating system that reconciles brokerage data, manual assets, and deterministic scenarios behind a bounded AI interface.

Product & systems engineering

  • Python / FastAPI
  • PostgreSQL
  • Next.js / TypeScript
  • Docker
View case study : Treasury

How I build

AI expands what I can implement. The decisions and the checks still matter.

  1. Understand

    Start with the problem, the people, and the constraints.

  2. Design

    Make product decisions and system boundaries explicit.

  3. Build

    Use AI for implementation leverage, not as a substitute for judgment.

  4. Validate

    Test behavior, failure paths, and the assumptions that matter.

  5. Iterate

    Use evidence to decide what needs to change.

Not a one-way handoff. Each validation step can send the work back to an earlier decision.

A little context

From the firmware
to the person using it.

My background is in firmware and software engineering. I approach products as systems: the technical architecture, the workflow, and the people using it need to work together.

More about me

Engineering notes

Bugs worth remembering, architecture choices that took some thought, and experiments that changed how I work.

All notes

Product / Systems / People

Start with the problem.

Contact