Skip to content

Nathan Bissett · Software Engineer

I build software end-to-end — from real-time backends and production AI to cloud and iOS.

Open to work

About

Hi, I'm Nate.

I'm a software engineer with over a year of professional experience spanning a wide stack for a junior developer — real-time backend systems, production AI/LLM services, cloud, full-stack web, iOS, and embedded/IoT.

Most recently at FUH I worked on the architecture behind Emma, a real-time presence and calling system, and an AI clinical-intake service that turns conversation into validated structured data.

I like owning problems end-to-end — from sensors and embedded firmware, up through distributed backends, to the screen in someone's hand.

Right now I'm building Tippsy, a Go + Postgres + iOS app.

Flagship — in active development

Tippsy

A drink-discovery app, built start to finish.

In active development — shipping to TestFlight.

The problem

Finding a drink you'll actually enjoy means wading through generic lists that ignore your taste. Tippsy is a mobile app for discovering drinks tailored to you — built start to finish, from the native iOS client down to the API and database.

Architecture

iOS (Swift)
Go REST API
PostgreSQL

Backend-only service, so the README is the demo — architecture, setup, and a diagram of it running.

Why this stack

Go
A simple, statically-typed API with first-class concurrency and a tiny deployment footprint — easy to reason about and cheap to run on a free tier.
PostgreSQL
Drinks, ingredients, users and preferences are inherently relational; Postgres gives strong consistency and mature tooling for query-driven features.
iOS (Swift)
A native client for a fast, platform-native feel — and since I build iOS, the whole stack stays first-party and end-to-end mine.

Build log

  • REST over GraphQL

    The data model is straightforward, so REST keeps the iOS client simple and the API easy to cache and reason about.

  • Relational model first

    Modeled drinks/ingredients/preferences in Postgres up front so filtering and recommendations stay query-driven rather than bolted on.

  • Testable service boundaries

    Separated HTTP handlers from the data store so the API can be tested without a live database.

Case study — FUH

Systems work at FUH

My strongest work is under NDA, so I can't share the code. But I can share some of the design and reasoning around two major projects.

Emma

Real-time presence & calling

A real-time presence and calling system for connected devices. I worked on how devices announce availability and how calls route reliably across unreliable networks.

  • TTL-expiring presence → fails toward 'unavailable'
  • multi-device fallback in priority order
Devices publish presence over MQTT/TLS to a presence and routing service, which drives a call state machine; a logical user can own multiple devices that routing tries in priority order.
Presence model
Devices publish heartbeats and status to a presence service; stale presence expires on a TTL, so the system fails toward 'unavailable' instead of ringing a dead endpoint.
MQTT over TLS
Low-latency pub/sub messaging between devices and backend over an encrypted transport, with topic-scoped authorization per device.
Call state machine
The call lifecycle (idle → ringing → connected → ended/failed) is modeled as an explicit state machine, so every transition is observable and recoverable.
Multi-device fallback
A logical user can own several devices; routing tries them in priority order and degrades gracefully when one is unreachable.
  • ~99% reliability during early rollout

AI clinical-intake service

Production LLM pipeline

A service that turns a freeform patient conversation into validated, structured data for downstream systems — a production LLM pipeline with safety rails.

  • ↺ model fallback on error / timeout / low confidence
  • audit log written at every step
A conversation transcript is extracted by an LLM into output validated against a strict schema, then emitted as structured data; a secondary model backs up the primary and every step is audit-logged.
Conversation → structured output
A transcript is passed through an LLM extraction step that emits structured output conforming to a strict, typed schema.
Schema validation
Every model response is validated against the schema; invalid or missing fields are rejected or re-prompted rather than passed downstream.
Model fallback
A primary model with automatic fallback to a secondary on error, timeout, or low confidence, so the service degrades instead of failing.
Audit logging
Every request, response, and decision is logged for traceability and review — essential in a clinical context.

More work

Projects

Cheer

Accessible, deployed full-stack web app.

Problem

My cleanest academic full-stack build — an end-to-end web app taken from zero to a live, authenticated, accessible deployment.

My role

Built the full stack — React/Next front end, authentication, and a GCP deployment — with WCAG-compliant accessibility throughout.

React / Next.jsGoogle CloudAuthWCAG / a11y
  • Cleanest academic full-stack build
  • WCAG-accessible by design

LolaBees

Hardware + cloud for healthier hives.

Problem

Beekeepers lose hives to conditions they can't see until it's too late — by the time a colony shows visible trouble, the loss is often already underway.

My role

Led a team of 4, owning the end-to-end system design across the sensor hardware and the cloud dashboard.

Embedded / IoTSensors + firmwareCloud dashboard
  • 2nd place out of 13 teams
  • ~40% reduction in hive loss
  • Real hardware feeding a live cloud dashboard

Toolbox

Skills

Languages
GoSwiftTypeScriptPython
Backend & infra
PostgreSQLMQTTREST APIsGoogle CloudVercel
Frontend
ReactNext.jsTailwindWCAG / a11y
Mobile & embedded
iOS (Swift)Embedded / IoT

Contact

Let's talk

I enjoy working on a full stack with an emphasis on AI and am open to new opportunities. I'm happy to talk through any of the work above, the fastest way to reach me is by email:

nathanbissett906@gmail.com