Suleiman Francis
Software Engineer building production web, mobile, and AI-powered products.
I’m a Software Engineer focused on building production web, mobile, and AI-powered products.
My work spans frontend, backend, mobile development, and AI integration, with a focus on turning complex requirements into reliable, maintainable software.
I’ve worked across SaaS, customer feedback, healthcare, community platforms, and internal enterprise systems, collaborating with product and engineering teams from requirements through implementation and production delivery.
I care about more than getting a feature to work. I care about architecture, maintainability, performance, testing, observability, and the experience people have when using the software.
Experience
- 2025 — PresentMobile & Frontend Engineer, Whistler
- 2023 — PresentFrontend / Full-Stack Engineer, SeamHealth Group
- 2022 — 2023Software Developer, Nigeria Civil Defence Corps HQ
Core disciplines
- Frontend →
- Designing resilient frontend architecture
- Backend →
- Building reliable realtime experiences
- Mobile →
- Shipping cross-platform mobile software
- AI / LLM →
- Building practical AI features
Selected technologies
- React, Angular, Next.js, TypeScript, JavaScript
- Node.js, Python, FastAPI, Express, REST APIs
- React Native, Expo, Flutter, Offline-first architecture, Push notifications
- LLM evaluation, RLHF, OpenAI and Anthropic APIs, Prompt engineering, Response evaluation
- Git and GitHub, CI/CD (GitHub Actions), Docker, Testing (Vitest, Jest, Playwright, pytest), Cloudflare Workers
Current interests
- How ML features behave on real user input, and how to evaluate them honestly
- Offline-first and realtime behaviour on unreliable mobile networks
- Technical writing: decision records, acceptance criteria, documentation
- Open source collaboration
Professional principles
- Know who owns each piece of state
- Data the server owns is cached and invalidated; data the client owns lives in the client. Most stale-data bugs come from blurring the two.
- Report how a number was measured
- A metric without its methodology is a claim. I state the split, the sample and the basis — including when the honest answer is “not measured yet”.
- Design the failure path first
- Dropped sockets, 401s, empty lists, slow networks and low-confidence predictions are normal operating conditions, not edge cases.
- Ship small, observable changes
- Staged release channels, crash reporting and analytics make it possible to see what a change did in production instead of guessing.
- Write it down
- Acceptance criteria and documentation are part of the feature. They are how the next engineer often me understands why the code looks the way it does.