The core problem with social media publishing at scale is combinatorial complexity. A content creator managing five social accounts across three platforms, publishing in four content categories at different frequencies, needs to make hundreds of individual publishing decisions per month. No human manages that well manually. The scheduling tools available when SocialWebSuite was built either required too much manual input per post or were too rigid in how they handled content categories and timing.
The architecture challenge was designing a system that could encode a user’s content strategy - their category mix, platform preferences, time slot configuration, and content source connections - and execute it reliably in the background with zero manual intervention once configured. That required solving several interconnected problems simultaneously: content category modelling, scheduling engine reliability at scale, multi-platform integration abstraction, and performance data surfacing.
Scheduling Engine
The scheduling engine is the operational core. The TimeSlotShareHelper runs every minute via a scheduled Artisan command, evaluates which time slots are active across all user schedules, and dispatches queued content for those slots.
withoutOverlapping Constraint
The most critical architectural decision in the scheduling engine. A naive approach - query all due content items and dispatch them - breaks under load: if a dispatch run takes more than a minute, the next scheduled run starts before the first finishes, creating duplicate posts. The withoutOverlapping constraint on the Artisan command acquires a lock, processes all due time slots, and releases the lock before the next run is allowed to start. Duplicate posts at scale are not a minor inconvenience for a publishing platform - they are a trust-destroying product failure.
Named Command Registration (publish-scheduled)
The scheduler dashboard gives operators direct visibility into whether the command is running, stuck, or missing without needing to inspect application logs. Production monitoring runs the logSystemStatsCommand every 30 minutes, reporting server load and lock file status - so a stuck scheduler is surfaced as an operational alert before users experience publishing failures.
Content Category System
Separating What from When and Where
A ContentCategory has a name, settings, and multiple ContentCategoryItems (individual pieces of content). It also has ContentCategorySources - connections to RSS feeds, WordPress sites via the platform’s own plugin, or manual content entry - that populate the item queue automatically. The per-category schedule configuration controls how items from that category flow into the publishing queue: frequency, platforms, time windows, and rotation rules.
User-Facing Content Strategy Model
Users create categories to represent content themes - Industry News, Product Updates, Curated Links - and configure how content from each category flows into their social publishing queue. The model separates the what (content and thematic classification) from the when and where (scheduling and platform selection), giving users fine-grained control over their publishing mix without managing every post individually.
Multi-Platform Integration Layer
Twitter, LinkedIn, Buffer
Twitter, LinkedIn, and Buffer integrations through a shared facade layer (TwitterUtil, LinkedinShare) that abstracts platform-specific API differences behind a consistent publish interface. Platform-specific rate limits, authentication models, and content constraints handled within each integration without exposing those differences to the scheduling engine.
RSS Feed Aggregation
A background refreshFeedsCommand populating ContentCategoryItems from configured RSS sources on each run, keeping content queues full for categories configured to pull from external feeds. The aggregation runs continuously so user content queues are always populated without manual content entry.
WordPress Plugin Sync
The platform’s own WordPress plugin enables site-to-platform content sync - WordPress posts flowing into ContentCategoryItems as a content source. The Knowledge Base theme built for SocialWebSuite’s help documentation (help.socialwebsuite.com) was also developed as part of the broader platform infrastructure.
Analytics, Onboarding, and Billing
Bit.ly Analytics Pipeline
Link statistics collected daily via the Bit.ly API, aggregating click and engagement data per account. The weekly report email command - running Monday mornings for all active accounts - compiled this data into per-account performance summaries and delivered them through a structured email template connecting performance data back to content strategy decisions.
Onboarding Wizard Event Architecture
Laravel events (WizardStepFinished, AlertAdmin) route new users through the onboarding sequence and alert the admin team to accounts that started but did not complete setup - a key retention signal for a SaaS onboarding funnel. Event-driven architecture keeps the wizard logic decoupled from the step execution code.
AppSumo Lifetime Deal Integration
A lifetime deal campaign required handling a subscription type entirely outside the normal Spark/Stripe billing flow. AppSumo customers paid once for lifetime access; the integration validated AppSumo license keys, provisioned the correct account tier, and handled refunds and upgrades through AppSumo’s own API. Isolated into its own controller (AppsumoController) and listener chain to prevent the AppSumo code path from disrupting the existing subscription system.
Policy-Based Multi-Tenancy
SitePolicy and SocMediaPolicy isolate each user’s connected sites and social accounts, ensuring no cross-account data access regardless of how API requests are constructed. Multi-tenancy enforced at the policy layer rather than at the query layer means a missing scope does not silently expose one user’s accounts to another.
SocialWebSuite ran from 2018 to 2024. Designing a platform, building it, taking it to market (AppSumo campaign), and maintaining and extending it over six years is a different kind of engagement than a project build. The scheduling engine decisions made in 2018 had to hold up under six years of account growth, API changes across three social platforms, and a significant user influx from the AppSumo campaign.
The withoutOverlapping scheduling architecture, the content category model, and the AppSumo billing isolation are the three architectural decisions that most clearly demonstrate the SaaS design thinking that underpins the custom WordPress and WooCommerce platform work on the rest of this portfolio.
