How to Make an App Like PetCube

Building a connected pet camera app involves more moving parts than most founders expect. This post breaks down the architecture, real-time protocols, hardware integration challenges, and monetisation mechanics you need to get right before writing a line of code.

What Does an App Like PetCube Actually Do Under the Hood?

PetCube is not just a video streaming app with a pet theme. It combines several distinct technical systems that need to work together reliably.

At its core, the platform has four layers:

• A firmware-side embedded system running on the camera hardware
• A real-time media pipeline for video and audio
• A mobile and web client that renders the stream and handles user interaction
• A cloud backend managing device state, notifications, user accounts, and recordings

Each layer has its own failure modes and scaling characteristics. Treating this as a single "video app" problem is how projects go sideways in month three.

The Camera Hardware Side

PetCube-style cameras run on SoCs (system-on-chip) like the Ambarella H22 or Ingenic T series, which have onboard H.264/H.265 encoding. The firmware typically runs on a stripped-down Linux image, with an SDK from the chip vendor handling ISP and codec pipelines.

If you are building a white-label device or using a third-party camera module, you will be working with RTSP streams at the hardware boundary. Most OEM cameras expose an RTSP endpoint locally. Your job is to pull that stream, transcode or relay it, and deliver it to clients efficiently.

If you are designing the hardware yourself, budget 6–9 months for bring-up, certification (FCC, CE, BIS in India), and firmware stabilisation. That timeline is realistic, not pessimistic.

How Do You Stream Live Video With Under Two Seconds of Latency?

Latency is the hardest constraint in a pet camera app. Users expect to see their pet in near-real-time, and features like two-way audio and the laser pointer (PetCube's signature feature) are broken above roughly 1.5 seconds of end-to-end delay.

WebRTC is the right answer here. It gives you sub-500ms latency over a properly tuned STUN/TURN infrastructure and handles NAT traversal natively. The signalling layer is typically WebSocket-based, and you can use open-source media servers like mediasoup (Node.js) or Pion (Go) to handle the SFU (Selective Forwarding Unit) logic.

RTMP and HLS are common alternatives but they introduce 3–10 seconds of latency by design. They are acceptable for recorded playback but not for live interaction.

One practical constraint: WebRTC requires the camera to act as a WebRTC peer, which means you either need a camera SDK that supports it natively or a relay process running on the device or a nearby edge node. For resource-constrained devices, a TURN-based relay architecture where the camera pushes RTSP and a lightweight edge proxy converts to WebRTC is a reasonable middle ground.

TURN Server Sizing and Cost

TURN relays traffic when peer-to-peer fails, which happens on roughly 15–20% of connections depending on network conditions. TURN bandwidth is your biggest cloud cost at scale. At 720p/30fps, a single H.264 stream runs around 1.5–2 Mbps. At 10,000 concurrent users with 20% on TURN, that is 3–4 Gbps of relay traffic. Price that before you commit to a WebRTC architecture.

Coturn is the standard open-source TURN server. Twilio's Network Traversal Service and Cloudflare Calls are managed alternatives worth evaluating if you want to skip ops overhead early on.

Designing the Cloud Backend

The backend is a collection of distinct services, and they have different scaling profiles.

Service	Scaling Dimension	Suggested Stack
Signalling server	Concurrent WebSocket connections	Node.js + Redis pub/sub
Media relay (TURN/SFU)	Bandwidth	Coturn, mediasoup on dedicated VMs
Event pipeline (motion alerts)	Message throughput	Kafka or AWS Kinesis
Recording storage	Storage volume	S3-compatible object store
Device management	Device count	MQTT broker (EMQX or AWS IoT Core)
REST API	Request rate	Go or FastAPI, horizontally scaled

Device management deserves particular attention. Cameras are IoT endpoints that need OTA firmware updates, remote configuration, and health telemetry. MQTT over TLS with certificate-based device identity is the standard approach. AWS IoT Core handles this well at scale, though at significant per-message cost once you are past 100,000 devices.

Motion detection and alert logic can run either on-device (if the SoC supports it) or on the cloud via a CV pipeline. On-device inference using a model quantised to INT8 and running on the SoC's NPU avoids the latency and bandwidth cost of sending video frames to the cloud for analysis. Tools like TensorFlow Lite and ONNX Runtime make this feasible on modern camera SoCs.

What Does the Mobile App Architecture Look Like?

The mobile client has two main jobs: render a live WebRTC stream and provide the interaction layer (PTZ control, two-way audio, clip playback, subscription management).

React Native is the sensible cross-platform choice if your team is JS-heavy and you want a single codebase for iOS and Android. The caveat is that WebRTC in React Native relies on the react-native-webrtc library, which lags behind the native WebRTC spec and has historically had issues with audio routing on iOS. If real-time audio quality is a product differentiator, native Swift/Kotlin with the Google WebRTC framework gives you more control.

Flutter is a reasonable alternative, though the WebRTC ecosystem around it (flutter_webrtc) is smaller and you will hit fewer answered Stack Overflow questions.

For clip playback, ExoPlayer on Android and AVPlayer on iOS handle HLS efficiently. Keep this path separate from your live stream path in the architecture.

Push notifications for motion events should go through APNs and FCM. Keep notification payloads thin (device ID, event type, timestamp) and let the app fetch clip thumbnails on open. Sending image data in push payloads is unreliable and gets throttled.

Monetisation and Subscription Architecture

PetCube's core revenue model is a subscription tier called PetCube Care, which gates cloud recording, 24/7 vet access, and extended clip history. This is a standard SaaS subscription pattern, but the entitlement logic needs to be accurate at the edge.

Use a subscription management platform like RevenueCat if you are distributing through the App Store and Play Store. It normalises subscription state across both stores and handles restoration, cancellation, and grace periods. Rolling this yourself is a multi-month distraction.

Entitlement checks should happen server-side, not client-side. A client that checks its own subscription state is trivially bypassable.

Cloud storage costs are directly tied to recording retention periods. At 1080p with H.265, a continuous 24-hour recording runs roughly 7–10 GB per camera. Pricing tiers around retention length (7 days, 30 days, 60 days) is standard because it directly maps to your storage cost curve.

Conclusion

The technical surface area here is real: firmware, WebRTC, IoT device management, CV inference, mobile clients, and a subscription backend. None of it is unsolvable, but scoping it correctly at the start saves you from expensive re-architecture later.

The clearest next step is to define your hardware strategy first. Whether you are buying an OEM module, designing custom hardware, or building software-only for existing cameras determines everything downstream, from the streaming architecture to the OTA update pipeline. Get that decision documented before you write backend code.

---

FAQ

How long does it take to build a pet camera app like PetCube? A minimum viable version covering live streaming, motion alerts, clip storage, and a mobile app takes 9–14 months with a team of 6–8 engineers. Hardware development adds 6–9 months if you are building a custom device. The subscription and entitlement layer is often underestimated and adds 4–6 weeks on its own.

What is the biggest technical risk in a PetCube-style app? Real-time latency under adverse network conditions. WebRTC handles it well, but TURN relay costs at scale and maintaining sub-1.5 second latency across different ISPs and mobile networks requires ongoing infrastructure tuning. Most teams underestimate this until they are in production.

Do you need custom hardware to build this? No. Several OEM manufacturers, particularly in Shenzhen, produce Wi-Fi cameras with RTSP output that you can use as the hardware layer. This trades control and margin for speed. If differentiated hardware is a product requirement (form factor, IR range, audio quality), custom development is worth the time and cost.

How much does cloud infrastructure cost at scale? At 100,000 active cameras with average 2-hour daily viewing, TURN relay bandwidth alone can run $15,000–$40,000 per month depending on TURN usage percentage and your CDN pricing. Motion detection CV inference and cloud recording storage are additional. Model these costs before finalising your subscription pricing.

Is on-device AI inference practical for motion detection? Yes, on modern camera SoCs with dedicated NPUs. A MobileNetV2 or EfficientDet model quantised to INT8 can run at 10–15 fps on a mid-range SoC with under 200mW additional power draw. The trade-off is a more complex firmware development pipeline and longer OTA update cycles when you retrain the model.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.