Cloud-native architecture
Context
The situation before the platform
Why social teams needed one workspace instead of six logins, six analytics views and a spreadsheet.
| The business |
A software product serving individuals, marketing agencies and businesses that manage a presence across several social networks at once, alongside the in-house teams who plan, approve and publish that content. |
| The starting point |
Managing multiple accounts meant logging in and out of disconnected tools. Each channel had its own login, analytics and posting system, and none of them worked together — a collection of tabs rather than a view of what was going out and what was performing. |
| The trigger |
Six networks with six different API schemas, rate limits and undocumented changes had to be normalised into one dashboard where scheduling, analytics and engagement could be trusted — without a platform update quietly breaking reporting. |
| What they wanted |
One workspace combining smart scheduling, unified analytics, team collaboration, content curation and a single social inbox, consistent across web, Android and iOS for solo operators and multi-brand agencies alike. |
| Constraints |
Third-party social APIs change without warning and enforce strict rate limits · data returned by each network arrives in a different format and had to be reconciled before it reached a user · role-based access had to keep agency and client work separated · heavy backend processing could not be allowed to slow the interface down. |
System
What it runs at today
The platform as delivered, live across web and mobile.
Subscription growth
15%
Growth in subscriptions as teams consolidated their social tooling into one paid workspace
Networks integrated
6+
Facebook, Instagram, LinkedIn, X, YouTube and Pinterest managed from a single dashboard
Engagement length
36+
Months, with a dedicated product team through build and continued scaling
Team size
5+
Designers, engineers and QA covering web, Android, iOS and backend
The engineering problem
Five gaps that shaped the build from day one
Not vague pain points — the specific tensions in making six independent networks behave like one product, each paired with what we did about it.
0
1
Six logins, no single view of what was going out
Teams were logging in and out of separate platforms to manage each social account. There was no unified view of what was published, what was performing or what needed attention — just a set of disconnected tabs. The constant switching slowed workflows and made day-to-day management exhausting.
What we did
A unified multi-platform command center that brings Facebook, Instagram, LinkedIn, X, YouTube and Pinterest into one dashboard, so managing, scheduling and engaging happen without leaving the workspace.
0
2
Every network measured performance differently
Comparing results across channels meant manual exports, copy-pasting into spreadsheets and educated guesses. There was no reliable way to see the bigger picture, so teams struggled to make confident, data-driven decisions about future campaigns.
What we did
A centralised data architecture that normalises inputs from six schemas into one reporting model, feeding consolidated live analytics and readable charts instead of exported spreadsheets.
0
3
Planning content across platforms took several tools
Campaign timing was inconsistent and no single calendar showed what was scheduled where. As content volume grew, meeting deadlines and holding a consistent posting rhythm became progressively harder.
What we did
A smart scheduling engine with one calendar for every connected channel, backed by a server-side job layer that handles concurrent scheduling work so publishing stays on time.
0
4
Drafts in email, approvals in chat, no record of changes
Agencies and in-house teams had no shared workspace. Content drafts lived in email threads, approvals happened over chat, and nobody had a clear record of who changed what or when. The missing visibility caused delays, duplicated effort and communication gaps.
What we did
Role-based team collaboration inside one account: shared dashboards, drafts and analytics with permissions controlling who can create, review and publish, so accountability is part of the workflow.
0
5
Third-party social APIs are unpredictable
Rate limits, undocumented changes and inconsistent data formats made it hard to build reliable features on top of the networks, and harder still to trust the data surfaced to users. Even a minor API change could disrupt workflows and distort reporting.
What we did
A dedicated API management layer handling rate limits, retries and version changes without cascading failures, plus post-launch monitoring of all six platform changelogs so breaking changes are caught before users are affected.
Architecture
How it fits together
Simplified — the shape rather than every service.
0
1
Clients
Angular.js Web App · Android App · iOS App · HTML · CSS · JavaScript
The web interface was built in Angular.js with a component structure that mirrors how users actually navigate the tool, with Android and iOS apps developed alongside it so the same workspace is reachable from a desk or a phone.
0
2
Gateway
Laravel API Layer · API Management & Rate Limiting · Permissions & Roles
A Laravel API surface fronts every client request and carries the user permission logic, with a dedicated management layer absorbing the rate limits, retries and version changes the social networks impose.
0
3
Services
Scheduling Engine · Analytics Aggregation · Social Inbox · Collaboration & Approvals · Reporting & Dashboards
Each function is its own concern, so scheduling jobs, webhook handling, analytics aggregation and collaboration can be tuned or extended without one platform's API behaviour destabilising the rest.
0
4
Data & infra
MySQL · Normalised Data Model · Auto-scaling Cloud · Load Balancing
MySQL holds normalised content, account and analytics data, deployed on scalable cloud infrastructure with auto-scaling, load balancing and secure storage for headroom as user numbers and traffic grow.
The heavy processing — concurrent scheduling jobs, webhook intake and analytics aggregation — is deliberately kept server-side, which is what allows the frontend to stay fast while six platforms are being reconciled behind it.
Solutions
Six systems doing the actual work
Not a features list — the specific things we built behind every number above.
Smart content scheduling & publishing
Users plan, schedule and publish across multiple networks from a single interface, holding a consistent brand presence without working through each platform's own tooling.
Data-driven visibility
Performance data from every connected platform lands in one reporting view, showing what is working, what is not, and what to prioritise next.
Live analytics & instant updates
Analytics refresh continuously, so teams work from current numbers rather than yesterday's and can respond quickly to shifts in trends and audience behaviour.
Unified social inbox
Comments, direct messages and brand mentions from every platform flow into a single inbox, which is what makes audience engagement manageable at scale.
Personalised dashboards & reporting
Teams build and configure their own views around the accounts they manage and the KPIs they care about, with custom reporting that needs no technical help to set up.
Collaborative decision-making
Multiple team members work inside the same account with role-based permissions controlling access and actions, improving coordination while keeping accountability intact.
Key features
What the platform does day to day
Five capabilities, each closing one of the gaps identified above.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Unified multi-platform command center | All accounts | Continuous | Brings every major social platform into one dashboard for managing, scheduling and engaging |
| Real-time cross-platform analytics | All accounts | Real time | Consolidated live performance data that removes manual exports and gives instant insight |
| Smart content scheduling engine | Scheduled jobs | On schedule | Campaign planning from a single calendar with reliable, on-time publishing |
| Unified social inbox | Inbound | As received | Centralises messages, comments and mentions from all connected platforms |
| Role-based team collaboration | Per role | On change | Teams create, review and publish content while accountability stays traceable |
Integrations
How the moving parts plug in
Every network, and the AI and delivery services around them, reach the product through one managed API layer rather than being wired straight into features.
Connected systems
Meta API
Facebook and Instagram accounts
X and LinkedIn APIs
Publishing and performance data
YouTube and TikTok APIs
Video channel management
ChatGPT and SendGrid APIs
Content assistance and email delivery
↓
through one managed API layer ↓
Platform integration layer
Laravel API layer
One contract for every client
API management layer
Rate limits, retries, version changes
Permissions & roles
Who can create, review, publish
↓
into the core services ↓
Core services
Scheduling
Analytics
Social inbox
Collaboration
Reporting
Because six schemas are normalised once at intake, scheduling a post, measuring it and replying to the comments it attracts are three steps against the same data rather than three separate tools.
Security
What protects accounts, data and access
The platform holds connected social accounts and client performance data for multiple brands at once — so access control and reliability were designed in.
Role-based access controls
Permissions decide who can create, review and publish inside a shared account, so agencies and in-house teams collaborate without everyone holding the same rights.
Enterprise-grade security posture
Built with enterprise-grade security and a cloud-native architecture designed to scale, whether it is supporting a small agency or an enterprise running multiple brands.
Resilient cloud infrastructure
Auto-scaling, load balancing and secure storage keep the platform available and stable as user numbers and traffic grow rather than degrading under them.
Ongoing API change monitoring
API changelogs for all six networks are actively monitored post-launch, so an unannounced platform change is caught and resolved before it distorts reporting.
Process
How we got there
Five stages, starting with how social teams actually work rather than a feature list.
0
1
Discover
We mapped how social media managers, content teams and business owners actually work — their daily bottlenecks, what existing tools missed, and what a consolidated platform would need to do well.
0
2
Define
We set the scope: which platforms to integrate first, how the scheduling logic needed to behave, how analytics should be structured, and where collaboration fitted into the product architecture.
0
3
Design
Wireframes and interactive prototypes focused on reducing friction, with every UX decision driven by one question: how do we make managing six platforms feel like managing one?
0
4
Develop
A backend built to handle concurrent API calls across platforms, with a frontend flexible enough to absorb the different data structures each network returns. Android and iOS apps were developed alongside the web application.
0
5
Validate
Rigorous testing across API edge cases, scheduling logic, analytics accuracy and real-world usage. User acceptance testing surfaced friction points that were resolved before launch.
Business impact
What changed for the business
Beyond the headline numbers, three things social teams noticed first.
One centralised workspace
Content management, analytics, collaboration and reporting moved into a single platform, so teams work faster and stay aligned without switching between disconnected tools.
Publishing that stops eating the day
Planning a campaign from one calendar instead of several tools took the repetitive work out of publishing and made posting consistency achievable as volume grew.
A foundation built to keep adapting
Complex problems — unpredictable APIs, cross-platform data, scalable scheduling — were solved behind a simple interface, leaving a platform that adapts as networks and user demands evolve.
Commercial outcome
What the engineering choices are worth in operating terms
Every headline number traces back to a specific decision, not a vague platform effect.
| Engineering decision | Operating outcome | Measured effect |
|---|---|---|
| Smart scheduling engine on one calendar | Campaigns are planned and published in one place instead of platform by platform | 40% less workflow time |
| Normalised analytics across six schemas | Cross-channel performance is comparable without manual exports | 98% positive feedback |
| Friction-led interface and prototyping | New accounts connect channels and start publishing sooner | 20% faster onboarding |
| Unified inbox and role-based collaboration | Teams stay in the product for engagement and approvals rather than leaving it | 40% higher retention |
Stack
What it's built on
The actual technologies, not feature names with icons attached.
Frontend
- Angular.js
- HTML
- CSS
- JavaScript
Backend
- Laravel
- PHP
Data & infra
- MySQL
- Scalable cloud hosting
- Auto-scaling & load balancing
Integrations
- Meta API
- X API
- LinkedIn API
- YouTube API
- TikTok API
- ChatGPT API
- SendGrid API
Full case study
Get the complete write-up as a PDF
The same content on this page, plus the extended module breakdown and delivery phases, in a single document you can share internally.
- Full platform and integration architecture
- Discovery-to-launch process, phase by phase
- How unpredictable social APIs were handled
Download the case study
No spam • unsubscribe anytime • we’re here when you need us
More work
Other platform builds
Hospitality
Every stay, extraordinary.
Hospitality group transformed guest experiences through IoT-enabled room automation, reducing service requests by 58%
Hospitality group transformed guest experiences through IoT-enabled room automation, reducing service requests by 58%
IoT - Hospitality
Read the case study →