Photo contest

Contestant: register, submit photos, view own entries. Public or judges: browse gallery, vote or score. Admin: moderate submissions, manage categories, announce winners, export reports.

Photo upload, gallery layout, voting rules (one vote per user, judge panel, time windows), and moderation queue are the core — web-first or mobile when contestants shoot on phone.

Campaign open → user registers → submit entry → admin review (approve or reject) → publish to gallery → voting window → close voting → winners and notifications. Tayona was my full-stack build through this loop.

Each stage maps to admin actions and what users see. I document voting rules and moderation steps in the process flow so server and front ends do not invent different meanings for pending or published.

I lead mobile and full-stack work on live platforms at DSSI (Diverse System Solution Inc.) in the Philippines — food delivery, ride hailing, logistics, booking, e-commerce, and member portals. The flows and notes below come from that production work.

dexterbanastao.com is my portfolio and hire-me lane. For the company behind most of this delivery, ride, and commerce software, see dssi.international — context in the DSSI blog post.

I don't jump straight to screens. Every build starts with a process flow — who does what, in what order, and what status everyone sees at each step. That becomes the shared map for you, me, the server team, and testing.

Typical sequence: discovery call → list of roles and features → you sign off on the process flow → backend connection plan → mobile and web screens per role → connect everything → App Store or web launch → handoff notes. AI speeds up first drafts at each step; your sign-off stays human.

You get visibility at each step — not a black box and a surprise at launch.

For production mobile I use Framework7 and Cordova — one codebase that becomes apps in the Apple App Store and Google Play, with native features (camera, GPS, push notifications, file upload) where the product needs them.

I usually split by role: customer app, merchant or provider app, rider or courier app, and sometimes a lightweight admin app. Each role sees the right screens; all roles read the same order or job status from the server.

Before store submission I test on real phones — cold start, background resume, location permissions, and slow network on the paths that matter for your business.

I'm not siloed on mobile while the server team guesses what data each screen needs. I lead with the signed process flow and a written backend connection plan — who can do what, each status name, and what data each screen expects.

What the server team receives: a status diagram (order, trip, booking, or shipment steps), examples of data in and out, which role calls which function, and what happens when login fails or a step is invalid. PHP and MySQL on the server; secure database access; handlers that match what mobile and web already built against.

During build I review server changes for mismatches — renamed fields, missing statuses, login gaps — before testing wastes a week. When the plan must change, we update mobile and server in the same sprint. That coordination is how multi-role platforms stay in sync in production.

On solo or lead work I own mobile, the server connection plan, and often the PHP layer behind it. AI-assisted workflow means clear project rules in the repo — how screens should look, how the server should respond, security boundaries — plus repeatable playbooks for adding a screen or a payment step.

AI drafts mobile pages, server boilerplate, and PHP logic from the signed process flow. I review every change for security, plan alignment, and store rules before release. Other developers on the project get the same rules so output stays consistent.

Fast first drafts, careful launch — whether the product is delivery, booking, or a member portal. See AI engineering and AI engineer services.