PhoneDeck

The console for setting up a safe, controlled phone. Drag apps onto a live picture of the phone to lay it out, cap each app's screen time, and filter the web, all on one screen that behaves like the phone in your hand.

CLIENT
Internet-safety product company
ROLE
Lead developer, end to end
STACK
Vue.js · PHP · SQLite
A phone mockup with a home-screen grid of apps, next to an app store to drag apps from
FIG. 01 · Set a phone up by dragging apps onto it. The screen mirrors the phone's real home screen.
01 · THE PROBLEM

Make setup feel like the phone, not a config form.

Setting up a controlled phone usually means abstract forms: which apps are allowed, for how long, when. A non-technical parent or admin gets them wrong. And underneath, the old console was unreliable: edits didn't stick, saves failed silently, and one big save could freeze the screen for minutes with no obvious cause.

✕Setting a phone up through abstract forms, nothing that looks like the phone.
✕Edits and saves failed silently, so changes didn't stick.
✕A big save could freeze the screen for minutes, cause unknown.
02 · WHAT I BUILT

One screen for the whole phone.

→
Drag-and-drop home screen
The phone shows up as a live picture with a real home-screen grid. Drag apps onto it from an app store, rearrange them, remove them, and the layout saves as the phone's setup.
→
Per-app time limits
The same screen sets the time rules: a nightly break, a daily cap per app. What's on the phone and when it can be used live in one place.
→
Reliable, self-healing saves
A proper save-and-cancel flow with validation, and setups that rebuild from a safe default instead of dead-ending.
Per-app usage-time rules: a nightly break and a daily social-media cap
FIG. 02 · Per-app time limits: a nightly break and a daily social cap, set on the same screen.
A device-management dialog with a save-and-cancel commit flow
FIG. 03 · Managing a phone, with the save-and-cancel flow that made every edit reliable.
03 · THE HARD PART

Two freezes, neither where it looked.

5 workers→20
The freeze that wasn't a frontend bug
A save that hung for minutes looked like app code. It worked the first time, failed the second, and ran fine locally. The server had run out of worker processes, so I raised the ceiling from 5 to 20 and backed it with the memory math, which showed about 80% headroom left.
every keystroke→one request
Suggestions that hammered the server
The domain-suggestion lookup fired on every letter typed, so a long list meant hundreds of requests. Debouncing it left one request per pause, and the list stopped freezing.
0
SERIOUS BUGS
750+ hrs
OF TESTED WORK
v1.0
SHIPPED CLEAN
“It is more than one year that we work with Priyank, with more than 750 hours now, and we are highly appreciating the quality of this work. Communication is excellent, it is a pleasure to work with him. He is very careful to deliver fully tested versions, and we never had a serious bug, only small details to fix. He takes the time to be sure that he understands well what is asked, and there has been very few misunderstandings. The first full version of the Vue interface is excellent, and we continue with him towards 1.1. Last not least: he likes to do this work, and this gives a very good general atmosphere.”
NEXT CASE STUDY
AI automation, in production
→
© 2026 Priyank Maniar · Independent software developer ← Back to the surface