Platforms vs Products
A product solves a problem. A platform enables solving problems.
The distinction matters. Products have boundaries--they do specific things for specific users. Platforms have interfaces--they enable others to build what they need.
Platform thinking is infrastructure thinking applied to software design. You're not building the final solution. You're building the system that enables solutions.
The API-First Mindset
Platforms start with APIs. Before UI, before features, define the interfaces:
What entities exist?: Users, documents, projects, whatever your domain requires.
What operations are possible?: CRUD, search, batch operations, relationships.
How do entities relate?: A document belongs to a project belongs to an organization.
What events occur?: Created, updated, deleted, accessed. What should trigger notifications?
Design the API as if you're building for external developers, even if the only consumer is your own UI. This discipline produces cleaner interfaces.
Composability Principles
Platforms enable composition. Components should combine in ways the designer didn't anticipate:
Single responsibility: Each component does one thing well. Combine components for complex behaviors.
Clean interfaces: What goes in, what comes out, what can fail. No hidden dependencies.
Stateless where possible: Components that don't maintain state are easier to compose and scale.
Idempotent operations: Operations that can be safely retried enable robust composition.
Event-driven coupling: Loose coupling through events rather than direct calls. Components react to what happened without tight integration.
When components are composable, the platform supports use cases you never imagined.
Extensibility Architecture
Platforms grow through extension, not modification:
Plugin systems: Allow custom code to hook into defined extension points. Users add capability without changing core.
Configuration over code: Many customizations don't need code. Expose configuration that covers common needs.
Webhooks: Notify external systems when events occur. Let users integrate with their ecosystem.
Custom fields: Domains vary. Let users add fields that matter to them.
Workflow customization: Standard processes with customizable steps.
Design for the 80% case in the core. Enable the 20% through extension. Don't try to build every variation.
Authentication and Authorization
Every platform needs identity and access control:
Authentication: Who is this? User accounts, API keys, service tokens.
Authorization: What can they do? Roles, permissions, ownership, sharing.
Multi-tenancy: Data isolation between organizations. Critical for trust.
API key management: Generate, rotate, revoke. Scoped to specific permissions.
Audit logging: Who did what, when. Essential for security and compliance.
Authentication and authorization are infrastructure. Get them right early. Retrofitting is painful.
Data Architecture for Platforms
Platform data has specific requirements:
Schema flexibility: Users want custom fields. Support dynamic schemas or key-value extensions.
Relationship modeling: Entities relate to other entities. Graph-like queries often needed.
Versioning: Data changes. Track history for audit, undo, and analysis.
Soft deletes: "Deleted" data is often recoverable. Soft deletes preserve while hiding.
Multi-region considerations: Users in different regions may have data residency requirements.
The data layer is the foundation. Architectural constraints here propagate through everything built on top.
Performance at Platform Scale
Platforms serve many users with varied workloads:
Caching layers: Frequently accessed data should be cached. Invalidation is the hard problem.
Rate limiting: Protect the platform from overload. Fair allocation of resources.
Async processing: Long operations shouldn't block. Queue and process in background.
Read replicas: Scale reads independently from writes.
CDN distribution: Static assets and cached content close to users.
Graceful degradation: When overloaded, degrade gracefully rather than collapse entirely.
Performance architecture is insurance. You don't need it until you do, and then it's urgent.
Developer Experience
If building for other developers, DX matters:
Documentation: Clear, complete, current. Examples for common use cases.
SDKs: Language-specific libraries that make the API pleasant to use.
Sandboxes: Test environments where developers can experiment safely.
Error messages: When things fail, explain why clearly. Suggest fixes.
Versioning: APIs evolve. Version them so existing integrations don't break.
Support channels: When documentation fails, developers need help.
Developer experience determines adoption. A powerful platform with poor DX loses to a simpler one that's pleasant to use.
Platform Evolution
Platforms must evolve without breaking users:
Semantic versioning: Communicate what kind of change this is. Breaking changes get major versions.
Deprecation periods: Warn before removing features. Give users time to adapt.
Migration support: Tools and documentation for transitioning between versions.
Feature flags: Ship features behind flags. Enable gradually. Roll back if problems appear.
Backwards compatibility mindset: Every public interface is a commitment. Be thoughtful about what you expose.
The platforms that thrive evolve continuously while maintaining trust. Users need to know you won't break them.
Build vs Buy Analysis
When should you build a platform versus use existing ones?
Build when:
- Your domain is truly unique
- Existing solutions impose unacceptable constraints
- The platform is core to your competitive advantage
- Long-term cost of building beats long-term cost of buying
Buy when:
- Commoditized functionality (auth, payments, email)
- Time to market matters more than customization
- Maintenance burden of building isn't justified
- Existing solutions are genuinely good enough
Most applications should buy most infrastructure and build only what's differentiated. Platform thinking applies whether building or integrating.
Personal Platform Application
These principles apply to personal infrastructure too:
API mindset: Your personal tools should have clean interfaces. The MCP servers I build are APIs to my data.
Composability: Personal tools should combine. Knowledge graph query results feed into writing tools feed into publication.
Extensibility: As needs change, add capabilities without rebuilding everything.
Evolution: Personal systems grow with you. Design for change, not perfection.
Platform thinking isn't just for enterprises. It's a mindset that produces better systems at any scale.
Related: C1 discusses UX patterns for analytics platforms. A2 covers orchestration which platforms often require.