Jordan Bartak

I have been building software for over nine years. The common thread is simple: I work on systems where correctness matters.

I started in native iOS with Swift at Gro Software, building a cross platform CRM used by real teams doing real work. Mobile teaches you discipline fast. Performance is visible. Latency is obvious. State bugs show up immediately. I learned early that UI is never just UI. A button tap is a network decision, a caching strategy, a failure state, and a data contract. That shaped how I think about frontend systems.

At Norhart, I moved into full stack ownership. We took a product from concept to production in seven months. That meant defining API contracts, shaping the data model, building the frontend, and shipping infrastructure that could actually hold up. It was not about polishing features. It was about making architectural decisions that would not collapse under real usage. That experience forced me to think in systems instead of screens.

At Taxa, the complexity increased. We were building an AI driven tax platform on top of a tax engine. I led frontend architecture for a Next.js application built with TypeScript and Tailwind, with explicit boundaries between client state and server truth. We standardized on OpenAPI defined REST contracts so the system was predictable, testable, and easier to reason about as it grew. What started as a demo became the interface that secured continued investment in the company. The real challenge was not styling components. It was turning AI output and dense tax logic into workflows accountants could actually trust.

Most recently at Aiwyn, I operated at the intersection of frontend architecture and product design. My titles shifted between Director of Front End Engineering and Principal UX Designer, but the work was consistent: define frontend systems, raise the quality bar, and build interfaces for accounting workflows where auditability and permissions were not optional. That is the space I have grown into. Data heavy platforms. AI capabilities with constraints. Software that people depend on when mistakes are expensive.

I am based in Minnesota. The problems I work on are not small or local. They are structural. They require clear thinking and technical ownership.

When I say "trust critical," I mean products users rely on, not tolerate.

In trust-critical systems, correctness is not optional. Edge cases are not rare. They are guaranteed states. I design with that assumption.

That means I spend real time on permission boundaries, audit trails, deterministic state transitions, and failure modes. I care about whether a user can trace a number back to its source. I care about whether the UI reflects system truth, not just optimistic guesses. I separate server state from client state intentionally. I design workflows so that ambiguity is surfaced, not hidden.

With AI native products, the gap between prototype and production is huge. It is easy to show a model generating output. It is much harder to build an interface that communicates uncertainty, allows overrides, logs decisions, and prevents silent failure. My approach is to constrain the model behind explicit UI boundaries. Make assumptions visible. Give users control. Record what happened. Trust does not come from intelligence. It comes from transparency and guardrails.

I use React, Next.js, and TypeScript because they are practical and predictable. I reach for tools like Zustand and TanStack Query when they clarify state boundaries and reduce implicit behavior. I think about re render patterns, data normalization, and long term maintainability before I think about abstractions.

I evaluate new tools with one question: does this reduce complexity in the system, or just move it somewhere harder to see? I am not interested in hype cycles. I am interested in architectures that scale as product complexity increases.

Because I work between design and engineering, I translate in both directions. I can take a rough product idea and shape it into a coherent system with clear state boundaries and predictable behavior. I can also push back when a visual decision conflicts with data integrity, permissions, or long term maintainability.

I care about pixel level precision. Spacing, typography, motion, and interaction details are not afterthoughts for me. That level of care is part of how I build trust in a product. But visual polish only works when it reflects system truth. The goal is not just aesthetic quality. It is alignment between what the user sees and how the system actually behaves.

I do my best work on products where errors have consequences and clarity matters. Financial platforms. B2B systems. Data heavy workflows. AI features that need structure, not just demos.

I tend to operate at staff level scope, whether the title says it or not. I take ownership of frontend architecture, system boundaries, and the interface between backend complexity and user understanding. I am comfortable being accountable for that layer.

I am not interested in shipping surface level features. I am interested in building systems that hold up under pressure.