I build and own web and mobile products where reliability matters. Most recently, I led the frontend and mobile surface for Marani Health: an Angular clinical portal and two React Native patient apps, including a regulated BLE monitoring app. Before that, I co-founded a two-person healthcare software company and owned its frontend architecture from product decisions through delivery.
I've been building for the web since 2013. Architecture, testing, release automation, accessibility, and production support are part of how I take a product from an ambiguous problem to a dependable release. At Marani, that also meant working directly with clinical, product, hardware, QA, regulatory, and DevOps partners.
My deepest tools are TypeScript, Angular, and React Native. I have worked in Angular from version 2 through 22, modernizing live applications as the framework evolved. I also work at product seams: earlier Swift and Objective-C Cordova integrations; more recently BLE and offline synchronization, real-backend testing with Spring Boot and PostgreSQL, performance profiling, and CI/CD infrastructure.
JUL 2023–AUG 2026 · SOFTWARE ENGINEER, FRONTEND & MOBILE LEAD
Owned frontend and mobile architecture, delivery, quality, and production support across two patient apps and a clinical portal.
Two React Native apps plus an Angular portal in production at roughly 15 client organizations
43% shorter cycle from bug report or feature request to QA-testable code
Asset delivery size reduced 78%; deployment time cut 50%
Automated test and release pipeline supporting a release every 2–3 weeks
MARANI HEALTH · JUL 2023–AUG 2026 · SOFTWARE ENGINEER, FRONTEND & MOBILE LEAD
Marani Health builds maternal and fetal remote patient monitoring software: an Angular clinical portal, two React Native patient apps, and BLE wearable hardware.
End-to-end ownership. I owned frontend and mobile priorities, architecture, implementation, testing, deployment, store delivery, and production triage across national payers, health systems, perinatal practices, and grant-funded studies. I worked with clinical, product, hardware, QA, regulatory, and DevOps partners rather than treating the apps as isolated clients.
Regulated mobile. I built the Mother app, a React Native and Expo application that captures and processes fetal and maternal heart-rate data from wearable BLE hardware. I designed its error states and failure modes up front, documented architectural decisions for regulatory review, and treated verification as a safety control. I also took Mwrap from zero to production in about six weeks.
Platform architecture. I modernized the live clinical portal with standalone components, Signals, deliberate RxJS boundaries, and current Angular animation APIs. I also extended the forms system into a versioned, cross-platform survey and monitoring-protocol engine whose definitions render on web and mobile.
Engineering leverage. I built the organization’s test infrastructure from zero: Playwright UI and API suites, Jest, and Maestro mobile E2E, all gating releases. I published shared PostgreSQL seed images so web and mobile suites tested against identical data, and extracted repeated CI/CD work into reusable GitHub Actions consumed across the codebases.
Technical direction. I authored and maintained organization-wide ESLint, Prettier, and code-quality packages so coding standards stayed consistent across all codebases. I also maintained the shared TypeScript and React Native packages used across web and mobile, reviewed contractor code, and mentored a QA intern, a machine-learning intern, and two entry-level developers through test-strategy coaching, recurring technical check-ins, and code reviews that explained the reasoning behind team conventions.
Operational improvements. I used bundle analysis, compression, route-level delivery, and caching to improve performance for constrained devices and shorten releases. As the backup DevOps owner, I also introduced point-in-time-recovery database backups.
CUJONICS
PLATFORM ARCHITECTURE
MAY 2021–JUL 2023 · CO-FOUNDER & SOFTWARE ENGINEER
Two engineers turned a legacy Angular product into a configurable healthcare platform.
Owned frontend architecture, code standards, and review
Dynamic healthcare forms UI, real-time Chart.js reporting, three-tier notifications
One codebase for branded, feature-gated client deployments
Shared product strategy and delivery in a two-engineer company
CUJONICS · MAY 2021–JUL 2023 · CO-FOUNDER & SOFTWARE ENGINEER
Cujonics was a two-person software company building a HIPAA healthcare platform. Product strategy, requirements, design, architecture, review, and delivery were shared engineering responsibilities. I owned the frontend architecture and reworked the legacy TypeScript and Angular codebase into a component-based system.
I built the dynamic healthcare forms UI with custom validation and organization-wide sharing, a workflow engine that generated real-time Chart.js patient reports, and a three-tier notification system covering patients, organizations, and companies.
I designed a multi-client layer so one codebase could ship uniquely branded, feature-gated deployments through tokens, theming, reusable components, and configuration. That architecture made the product licensable to Marani Health. Marani licensed it and later hired both founders full time.
BIOANALYT
FRONTEND STANDARDS
MAY 2020–MAY 2021 · LEAD FRONTEND DEVELOPER
Took a proof of concept to a consumer product and wrote the team's frontend standards.
Grew a proof-of-concept MVP into a consumer-facing product
Wrote the frontend coding standards the team used going forward
BIOANALYT · MAY 2020–MAY 2021 · LEAD FRONTEND DEVELOPER
BioAnalyt is a food product-innovation company based in Teltow, Germany. They build portable rapid test kits that measure vitamin concentrations in food and biological fluids. I worked with them fully remote.
I took their proof-of-concept MVP and grew it into a fully functioning consumer-facing application. I wrote the frontend coding standards the team used going forward, and worked directly with the product manager on scoping: setting realistic expectations, then delivering within them.
BRIGHTFOX
DATA RELIABILITY
SEP 2019–MAY 2020 · DATA AGGREGATION ENGINEER
Fail-safe ingestion of 30+ healthcare systems. Hundreds of thousands of staffing positions.
Independent fail-safe modules: one source failing never blocked the rest
Ingested 30+ healthcare systems into the BrightFox database
BRIGHTFOX · SEP 2019–MAY 2020 · DATA AGGREGATION ENGINEER
BrightFox is a healthcare staffing marketplace connecting hospitals directly with workers.
I designed and built their data-extraction and transformation platform as a set of fully independent modules, so a failure pulling data from one health system never affected any other, and new systems could be added or changed on their own. The platform ingested 30+ healthcare systems and brought hundreds of thousands of hospital staffing positions from across the country into the BrightFox database.
I profiled and optimized it extensively across platforms and load conditions, working directly with the Chief Technology Architect. My time there was cut short when COVID-19 hit the business.
EARLIER CAREER4 ROLES · SELECT A ROLE TO READ MORE
WANNATRAIN
DELIVERY SYSTEMS
MAY 2018–AUG 2019 · APPLICATION SOFTWARE DEVELOPER
Shortened the release-candidate path across five time zones and three continents.
WANNATRAIN · MAY 2018–AUG 2019 · APPLICATION SOFTWARE DEVELOPER
WannaTrain is a wellness community app, built by a team spread across 3 continents and 5 time zones.
I set up a code-review testing environment that shortened our release-candidate process. I also prepared the product reports and demos used in investor meetings, and wrote technical architecture proposals for third-party integrations. Working across that many time zones taught me to be self-sufficient: if I hit a problem in the morning, nobody who could help was awake until that night.
UNIV. OF CINCINNATI
APPLICATION OWNERSHIP
JAN 2016–JAN 2017 · APPLICATION SOFTWARE DEVELOPER
Redesigned the department site and built automation that reduced manual review mistakes.
UNIV. OF CINCINNATI · JAN 2016–JAN 2017 · APPLICATION SOFTWARE DEVELOPER
I was the sole developer on a full redesign of the department's website and its web-based tools, and gathered the requirements myself from every department head.
Along the way I integrated Tableau visualizations for real-time reporting, and built review-automation software that reduced manual mistakes in the reporting process.
ATHLETIC PERF. TOOLS
FEATURE DELIVERY
MAY–SEP 2014 · JUNIOR DEVELOPER
First industry job. AngularJS feature work on a small team.
My first industry job. I did AngularJS and JavaScript feature work, and wrote technical proposals for integrating third-party software systems, on a small team where everyone shared in each other's successes.
FREELANCE WEB DEV
CLIENT DELIVERY
2013–PRESENT · FREELANCE WEB DEVELOPMENT
Small-business sites since 2013, still going part time, including the one you're reading.
FREELANCE WEB DEV · 2013–PRESENT · FREELANCE WEB DEVELOPMENT
Where it all started, and still going part time. I design, build, and maintain websites for small-business clients, including the one you're reading right now.
I freelanced under my own name from 2013 on; Omaha Digital Designs is the banner it runs under these days, founded a few years back.
CASE STUDIES
4 ENGINEERING DECISIONS · SELECT A CASE TO EXPAND
BLE MONITORING RELIABILITY · REGULATED MOBILE
CONTEXT AND STAKES
Patients used a wearable maternal and fetal monitor outside a controlled clinic. The React Native and Expo app had to capture and process heart-rate data from the proprietary BLE device, preserve the session through ordinary connection failures, and produce evidence that could withstand regulatory review.
MY SCOPE
I was the application's sole developer. I owned its architecture, BLE integration, session lifecycle, offline synchronization, verification strategy, release path, and submission documentation while coordinating with clinical, product, hardware, QA, regulatory, and DevOps partners.
CONSTRAINTS
The system crossed BLE hardware, iOS and Android behavior, older patient devices, unreliable home networks, and long-running monitoring sessions. Disconnects could happen mid-capture, and analytical processing belonged on the backend, so the app had to decrypt, correct packet gaps, assemble the continuous file, re-encrypt it, and deliver it without moving analytical processing into the mobile client.
DECISION
I designed error states and recovery paths before feature completion. The app persisted syncable session state locally, protected sensitive values with Expo SecureStore, queued interrupted delivery for retry, and kept acquisition, processing, and delivery on one traceable path. Test builds could substitute known simulator data without bypassing that production path.
SANITIZED ARCHITECTUREOne recovery-aware monitoring data path
Wearable or HIL rigPhysical signal → proprietary BLE device
→
Mobile session pipelineDecrypt · gap correction · file assembly · re-encrypt
→
Local retry queueOffline persistence · resumable delivery
→
Backend and clinical systemAnalytical processing · clinician workflow
QA SIMULATION PATH Known simulator data enters the same mobile processing and delivery path as live capture.
PRODUCTION INCIDENT AND FOLLOW-THROUGH
We limited over-the-air delivery to changes that did not touch native code. Even so, a production copy fix once replaced build-profile configuration and made internal QA controls visible to users for roughly 15 minutes. The controls were not safety-critical, but the configuration failure was unacceptable. I traced the change, shipped a corrective update, and force-logged-out active users to clear any changed settings. The permanent fix made production the fail-closed default and moved build-flavor detection to several independent checkpoints.
TRADE-OFFS
Offline persistence and retry increased state and recovery complexity, but a temporary network loss could not be allowed to discard a completed monitoring session.
The physical simulator gave the highest-fidelity evidence but was expensive and required a dedicated rig. A second simulated-data mode traded hardware fidelity for repeatable, broadly available full-pipeline testing.
FAILURE MODES AND VERIFICATION
Hardware-in-the-loop tests used a WhaleTeq simulator to drive physical leads connected to the real wearable, so the app received the same BLE stream it would receive from a patient. QA could also load a known file from the database and run it through the identical processing and delivery pipeline. Airplane-mode and mid-sync termination tests exercised the recovery paths. Separately, an automated SBOM scan across the codebases reported zero known vulnerabilities.
OUTCOME
The application and its quality and safety controls were submitted to the FDA under 510(k). The two-layer test approach gave the team both high-fidelity hardware evidence and a practical way to exercise the full pipeline without needing the physical rig for every run.
CONFIGURABLE CARE PLATFORM · PLATFORM ARCHITECTURE
CONTEXT AND STAKES
Cujonics was a two-engineer company building a remote patient monitoring platform for organizations with different branding, enabled features, and clinical workflows. Later, at Marani, clinicians also needed to collect different information from different patient populations without a new application release for every form.
MY SCOPE
At Cujonics I owned the frontend architecture, standards, and review process from product decisions through delivery. I designed the multi-client layer and the original dynamic forms UI. After Marani licensed the platform and hired both founders, I extended that foundation into surveys and monitoring protocols shared across the clinical portal and patient apps.
CONSTRAINTS
A two-person team could not maintain a fork for every client. A completely generic interface would erase the differentiation those clients required. The forms system also had to preserve custom validation and versioned definitions while rendering consistently in Angular and React Native.
DECISION
I kept one codebase and made variation explicit through design tokens, theming, reusable components, feature gates, and client configuration. For clinical content, I used shared, validated, versioned definitions with platform-specific renderers. We shipped the useful core first, then iterated on the definition model with clinicians as new workflows emerged.
TRADE-OFFS
Client forks would preserve unrestricted local control, but every fork would create its own drift, test surface, and release path. A single generic interface would be easier to maintain but would erase real branding and workflow differences. Tokens, feature gates, reusable components, and configuration kept those variations explicit inside one codebase.
Shared definitions eliminated duplicate content models, not platform-specific UI work. Angular and React Native still needed separate renderers, while custom validation and versioning became contracts both implementations had to honor.
FAILURE MODES AND VERIFICATION
The shipped product provided the proof: uniquely branded, feature-gated client deployments ran from one Angular codebase, while the same validated, versioned clinical definitions rendered in the Angular portal and patient apps. Marani licensed the platform, hired both founders, and continued evolving it into a product suite used by roughly 15 client organizations.
OUTCOME
The multi-client architecture made the Cujonics product licensable to Marani Health, which licensed the platform and later hired both founders full time. At Marani, I continued evolving the platform as part of a product suite running at roughly 15 client organizations.
LIVE PORTAL MODERNIZATION · ARCHITECTURE · DELIVERY
CONTEXT AND STAKES
Marani's Angular portal was a live clinical operations product. It needed newer architecture and faster feedback, but clinicians still depended on it and product work could not stop for a rewrite.
MY SCOPE
I owned the frontend architecture and modernization sequence. I also built the organization's test and release infrastructure, connecting portal changes to real-backend API verification, mobile coverage, shared test data, and repeatable delivery rather than treating modernization as a framework-only exercise.
CONSTRAINTS
The portal had to keep serving users through multiple Angular upgrades while a small engineering team continued feature work and production support. A clean-slate rewrite would recreate years of behavior before delivering value, and replacing every RxJS flow with a newer primitive would remove useful time and event semantics.
DECISION
I migrated incrementally to standalone components, current animation APIs, and a deliberate split in state management: Signals for synchronous view state and derived values; RxJS for event streams, asynchronous orchestration, debounce, retry, and cancellation. In parallel, I introduced Playwright UI and API suites against the real Spring Boot service with Testcontainers and PostgreSQL, Jest and Maestro coverage for mobile, shared GHCR seed images, and CI release gates.
TRADE-OFFS
Incremental migration required careful sequencing and a temporary mix of old and new patterns, but it preserved working clinical behavior and delivered improvements continuously instead of deferring all value until a rewrite finished.
A single reactive primitive would look simpler on an architecture diagram. Keeping Signals and RxJS at explicit boundaries produced a slightly broader mental model while preserving the strengths of each.
Real-backend integration tests cost more setup time and runtime than mocks. Testcontainers plus a shared seed image paid that cost to catch failures at the actual API and database boundary while keeping test data repeatable.
FAILURE MODES AND VERIFICATION
The Playwright UI and API suites ran in CI against the real Spring Boot service with Testcontainers and PostgreSQL. Shared PostgreSQL seed images in GHCR kept the portal and mobile suites on identical data, and the suites gated releases. Sentry supported production triage, while bundle audits and profiling covered route-level lazy loading, compression, and caching changes.
OUTCOME
The portal stayed in service throughout the migration. Cycle time from bug report or feature request to QA-testable code fell 43%. The automated test and release pipeline supported a release every two to three weeks. Compression and smarter delivery reduced asset delivery size by 78%, while caching cut deployment time by 50%.
FAULT-ISOLATED HEALTHCARE INGESTION · DATA RELIABILITY
CONTEXT AND STAKES
BrightFox was a healthcare staffing marketplace that needed to collect open positions from many hospital systems without allowing one unstable integration to stop the rest.
MY SCOPE
I designed and built the data-extraction and transformation platform, working directly with the Chief Technology Architect.
CONSTRAINTS
Source systems differed in behavior and could fail or change independently. New integrations also had to be added without destabilizing every existing source.
DECISION
I implemented each source as an independent extraction and transformation module with its own failure boundary. Shared orchestration could run the collection, while source-specific logic remained isolated enough to change and recover independently.
TRADE-OFFS
A highly generic connector framework would reduce repeated plumbing but force unlike systems into one abstraction. Independent modules preserved source-specific behavior at the cost of some repeated integration work.
More module boundaries increased the number of components to maintain, but kept one broken source from blocking the entire ingestion run and limited the blast radius of source-specific changes.
FAILURE MODES AND VERIFICATION
I profiled and optimized the platform across systems and load conditions. Modules could fail independently, and new healthcare-system integrations could be added or changed without coupling their extraction logic to the rest.
OUTCOME
The platform ingested 30+ healthcare systems and aggregated hundreds of thousands of hospital staffing positions into the BrightFox database.
EARLIER WORKFOUNDATIONAL PROJECTS · 2014–2020
SOCIALPNT
IOS PRODUCT
Solo-built social app spanning 84 screens, 45+ services, native plugins, and an App Store launch.
An augmented-reality historical tour; I led the team, client meetings, and AR integration.
INSPECTRUM
CLIENT WORK
A Firebase-backed fire-safety inspection dashboard built as the sole remote developer.
OPEN SOURCE
SELECT AN ITEM TO READ MORE
Upgrading ng2-pdf-viewer to pdf.js v4 had stalled after review feedback on a community pull request went unanswered.
The real blocker was that pdf.js v4 needs Promise.withResolvers. The earlier pull request solved that by requiring every consumer to upgrade to Angular 17. I picked the work back up, addressed the review feedback, and polyfilled the TC39 proposal instead.
The upgrade landed with backwards compatibility intact and closed two other pull requests and three open issues along the way.
I migrated i18n-js from lodash’s CommonJS build to lodash-es so bundlers could tree-shake unused utility functions. Because lodash-es is ESM-only, I also updated the Jest and Babel setup so the existing test suite continued to run.
The maintainer tested the change in browsers, React Native, and Expo, then released it in 4.5.4-alpha.0. The pull request remains open, so the accurate status is shipped in an alpha, not merged.
Repeated repository setup had become its own maintenance surface: package-manager detection, dependency caching, timezone configuration, and bot identity were copied between workflows. I extracted that behavior into three documented composite actions.
Each action has path-scoped tests with real fixtures covering Linux, macOS, Windows, invalid inputs, and fallback branches. That keeps unrelated commits from consuming runner time and gives each action an independent compatibility signal.
React Native Calendars hard-coded Timeline sizing and half-hour lines, which blocked a production requirement. I traced the constants through the Timeline and expandable-calendar code and carried a scoped patch-package change in the application.
I posted the full patch upstream: configurable hour-block height and half-hour lines, corrected animation-completion state, related sizing and padding fixes, and matching TypeScript definitions. I also stated the limit of the evidence clearly: I had tested the Timeline surface, not every possible use of the library.
The library's types were exported in a shape that stopped function types from being inferred properly, breaking builds and editor inspection for consumers.
I fixed the exports so inference worked again and sent the change upstream rather than carrying a private fork.
While Angular Signals patterns were still settling, I proposed a lazy async operator that would defer an API subscription until its value was first read, then recompute when an input signal changed.
I worked through alternatives publicly and posted a possible implementation, while explicitly calling out unresolved cleanup and memory-leak risk. The project later closed the proposal as not planned, so this is design exploration rather than a shipped solution.
“He constantly takes on new, challenging initiatives and delivers them with incredible quality. What sets Jordan apart is his proactive approach; he has a unique ability to anticipate company needs and quietly resolve complex problems.”
— Richard Dettinger, former VP of Software Development, Marani Health · View recommendation
“I'd happily work with him again.”
“I was consistently impressed by both his front-end development skills and his approach as a teammate. As a product leader, I particularly appreciated how easy he was to work with and how effectively he partnered across disciplines.”
— Todd Tucker, Sr. Director of Product Management, Modivcare (formerly VP of Product, Marani Health) · View recommendation