Portrait of Oyebola Feranmi Peter

About

I’m Peter, the software engineer behind Skybreaker. I build web and mobile products for teams whose work has become difficult to manage with disconnected tools or manual steps.

The work often spans several parts of a business: the interface people use, the server that holds the truth, the data underneath, and the outside services the operation already depends on. I stay useful when those parts have to move together.

I have built software for operations, community products, publishing, education, shops, connected devices, and service businesses. Some projects started from a blank page. Others began with a system that was already in use and needed to become easier to run.

Why Skybreaker

  1. One engineer can follow the whole problem

    A problem seen in the interface may begin in the database or in an external service. I can trace that path and make changes across the product without losing sight of the person using it.

  2. Existing software is welcome

    Many useful projects begin with code that already exists. I am comfortable reading an unfamiliar system. I find the risky areas and improve them in stages while current users still depend on the product.

  3. Failures are part of the design

    External services become unavailable. Mobile connections drop. The same event may arrive twice. I plan for those conditions and give operators enough information to recover.

  4. Technical decisions stay understandable

    I explain choices in terms of cost, delivery, user impact, and future maintenance. Technical readers can inspect the deeper reasoning, while other stakeholders can still take part in the decision.

  1. You explain what happens today.

    A technical brief is optional. Explain who does the work and what happens now. Tell me which part causes the most trouble.

  2. I map the work and identify unknowns.

    I review the current tools, data, risks, and decisions that could affect cost or delivery.

  3. We agree on the first release.

    The scope is written in plain language. Technical choices are explained where they affect the product or future maintenance.

  4. I build in visible stages.

    You see working progress, test important flows, and receive documentation for handover or continued support.

Frontend and mobile

  • Responsive web applications with Vue, Nuxt, React, and Next.js
  • Cross-platform mobile applications with Flutter and React Native
  • Forms, navigation, state management, accessibility, media, and offline behavior
  • Server-rendered pages and technical search optimization

Backend and data

  • Node.js services with NestJS and Express
  • REST API design, authentication, authorization, and request validation
  • PostgreSQL with Prisma, MongoDB, Firebase, and Supabase
  • Background jobs, scheduled tasks, file storage, and media delivery

Integrations and devices

  • Webhook processing and third-party APIs
  • Messaging, email, notification, and voice services
  • Smart-access, livestream-to-device, and connected-camera workflows
  • Retry handling, duplicate-event protection, and operational status tracking

Delivery

  • VPS and serverless deployment
  • Health checks, environment validation, and structured logging
  • API documentation and handover guides
  • Unit, integration, and behavior-focused tests
  • Maintenance, migration planning, and production troubleshooting

Languages

  • TypeScript
  • JavaScript
  • Dart
  • HTML
  • CSS