Ahmed Sozzer

Ahmed Sozzer · Experience

I get paid to delete the manual step.

Full-stack engineer at FYCLabs, a studio that builds products for startups. I work with the founders and the people using what we ship, and build the frontend, the backend and the pipeline that ships them. Three roles since 2024, and the same shape of problem in each.

the through-line three jobs, and one on my own time

  • component prices re-calibrated by hand → an ML pricing model on live supplier data
  • an insurance carrier silently dropping policy photos → nightly jobs that catch and resubmit them
  • students and staff signing in to seven portals → one sign-on in front of all of them, 50,000+ people a day
  • an operations team retyping between systems → CRM integrations that do the typing
  • a filament swap at every material change → AMS-X, on my own time

I noticed it late: the same problem, five times over.

Download the PDF of my résumé

01 current, remote (austin, tx) to now

FYCLabs

Full Stack Engineer (Engineer II). A studio that builds products for startups.

  • Next.js
  • React
  • TypeScript
  • PostgreSQL + Prisma
  • GCP
  • React Native
  • REST & webhooks

Insurance platform

Next.js, TypeScript, Node/Express, PostgreSQL, Prisma, BullMQ, GCP

The carrier was dropping our photos

I called the carrier’s endpoints directly in Postman, POST and GET, and went through the whole response, which listed every image attached to a policy. When I pulled the images themselves, most were empty structures with nothing stored in them. That was the proof that the carrier was silently dropping the photos we sent. After that I ran the weekly call with the carrier myself.

The fix on our side was to stop trusting the handoff. Overnight BullMQ jobs re-check every policy against the carrier and resubmit whatever it dropped. They caught about 10 broken policies out of roughly 300 that nobody had noticed, and anything odd now emails the team with its logs.

The slow queries got the same treatment: EXPLAIN ANALYZE to find them, composite indexes and raw SQL to fix them.

Education network single sign-on

Next.js, PostgreSQL, Prisma, AWS Amplify

One login across 3 new portals and 4 legacy ones, used by 50,000+ students, teachers, principals, district leaders and admins a day. The sign-on is its own Next.js app: it checks each Firebase-signed token with Firebase, confirms the user can open that portal, and redirects them in.

The plan was a repo per portal. The portals share one theme, so I talked the PM and the senior engineers out of it, and built one monorepo on a single Amplify deployment where subdomains split each portal’s routes.

Women’s health app

I built the React Native app from zero to launch and still own it. The client came back for a second phase. Front end and back end, I built the onboarding that places each user in one of 10 phenotypes, and the community where doctors, other users and an AI bot steered by the lead doctor answer each post.

Also at FYCLabs

On other client projects I wired GoHighLevel, Zoho and HubSpot into their backends over REST and webhooks, and set up CI/CD on GCP. I ship to production several times a week.

Two more from the same job

a different client: their backend, our mobile app

Five backends, one door

Their platform had grown into five separate services, each with its own login and its own idea of what a response looks like. The mobile app had to talk to all of them. I was the engineer closest to the client, so the integration was mine.

I put one typed layer over the whole thing, organised by subject rather than by service, so the other developer could call api.auth.signIn() and never learn which backend was behind it. When one of them changed, and they changed constantly, the fix happened in one file instead of across every screen that touched it.

I did consider putting a real service in the middle, which is the textbook answer. But a sixth deployable, pointed at five moving targets, is a maintenance bill with no ceiling. The client-side layer took two weeks, added nothing to run, and gave us one place to absorb whatever they did next.

  • 5 services behind one interface
  • 2 weeks to build the layer
  • <2 months for two of us to ship the app

The rewrite that did not happen

Their technical lead wanted to add a sixth service, in a new language, because one of their core features was slow. I had concerns, and they were mostly about us: nearly every bug we were chasing traced back to a change in one of their existing services, and a new one in a new language meant more of that, plus waiting on their team to build it.

I had asked for read access to their backend earlier, so I could understand what we were integrating against, and they had given it to me. Our contract was frontend only. I could not fix anything on their side, but I could see it. What I saw looked like an algorithm and a data-structure choice rather than anything a language would fix.

So I walked their lead through it: the specific problems we had been hitting, and the workarounds we were carrying on our side to absorb them. I brought the list and left the verdict to them. They agreed to look at what they already had first. Their team made a round of optimisations that cleared several bugs we had been flagging for weeks, and we shipped on schedule.

If they had insisted, I would have supported it. It is their system. I would have put the new service behind our layer so it did not slow the app down.

02 remote to

Holiday Channel: the whole store, built solo.

The store at Holiday Channel, built solo in React Native during my last semester at Illinois, from checkout through order fulfillment, and the iOS app taken from the Figma designs to an App Store release.

Those five months were also my last five months of coursework at Illinois. The degree finished in May; so did the platform.

Full Stack and iOS Developer at Holiday Channel

  • React Native
  • iOS
  • Figma

03 niles, il to

Luminii LLC: A price list that was being re-calibrated by hand.

Component costs moved with supplier data, and somebody adjusted them by hand. I replaced that with an ML pricing model fed by the live supplier feed. It was the first time I replaced a person’s recurring task with a system, and it’s why I look for that shape first. The database under it had outgrown its indexes, so I reindexed it and added automated validation, which is what made the query times usable.

Data Analyst and Software Intern at Luminii LLC

  • Python
  • SQL
  • ML

04 education

Education

A CS degree, and the research that came before it.

Wilbur Wright College

A.S., highest honors

I started at a two-year school and became the college’s first computer science tutor, teaching calculus, physics, chemistry and two semesters of C. That is how Dr. Espiritu found me and put me on her research into matching mentors with mentees. I co-authored the first version of the paper and presented it at Wright College in 2022 and at NEIU in 2023, and the published ASEE work-in-progress paper (PDF) acknowledges me by name.

University of Illinois Urbana-Champaign

B.S. Computer Science may 2025

Transferred from Wright with a cohort of friends.

Skills

the same list as the résumé

languages
  • TypeScript
  • JavaScript
  • SQL
  • Python
  • C++17
frontend
  • React
  • Next.js
  • React Native
  • Expo
  • WebRTC
backend
  • Node.js
  • Express
  • FastAPI
  • PostgreSQL
  • Prisma
  • Redis
  • BullMQ
  • REST
  • webhooks
  • WebSockets
  • MQTT
cloud and tooling
  • GCP
  • AWS Amplify
  • Firebase
  • Docker
  • CI/CD
  • Linux
  • Jest
  • Cypress
  • GoogleTest
ai-assisted development
  • Claude Code daily, with a spec review before any code and hooks and CI gating each change