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

An unusually broad junior

I'm a software engineer with about a year of professional experience spanning an unusually wide stack for a junior — 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, and I'm open to software roles.

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. What I can share is how the systems were designed — the patterns, the trade-offs, and my role. No proprietary code, no client or business specifics.

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

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

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

Toolbox

Skills

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

Contact

Let's talk

I'm open to software roles and happy to talk through any of the work above. The fastest way to reach me is email.

nathanbissett906@gmail.com