How We Built Our Core Platform: A Frontend Technology Journey

From Backstage to Next.js: Building CECG's Core Platform Dashboard

Core Platform dashboard, originally built as a Backstage plugin, was hitting its limits. While Backstage served us well as a starting point, our growing requirements for performance, customization, and user experience demanded a more flexible solution.

We needed to build a complex dashboard featuring data visualization, interactive tables, forms, and real-time updates that would serve both our internal teams and external stakeholders. The stakes were high—this wasn't just a UI refresh, but the foundation for how developers would interact with our entire platform ecosystem.

The Challenge: Choosing the Right Stack

As platform engineers at CECG, we don't just pick the latest trendy framework. Our approach reflects our core values: selecting mature, production-ready technologies that integrate seamlessly into end-to-end automated software delivery lifecycles. Every technology choice needs to excel not just in development, but throughout the entire journey of building, testing, releasing, and running applications at scale.

Our requirements were demanding:

Performance First: Server-side rendering for sub-1-second First Contentful Paint
Bundle Efficiency: Keep initial load under 500KB despite rich functionality
Developer Experience: Fast iteration cycles with hot reload under 500ms
Production Ready: TypeScript for safety, comprehensive testing, reliable CI/CD
Scalable Architecture: Support team growth and feature expansion
Accessibility: WCAG compliance for inclusive user experiences
Modern UX: Dark/light themes and responsive design

Our Technology Decisions and Results

After applying our systematic evaluation framework (which we'll share below), we landed on a powerful combination:

Framework: Next.js 15 with App Router

Built-in SSR/SSG eliminated complex setup overhead
Server Components delivered better performance through selective hydration
Turbopack provided significantly faster local development than Webpack
Production optimizations came out of the box

UI Library: Shadcn/ui with Radix Primitives

Copy-paste architecture gave us 100% component ownership
Tree-shakable components kept our bundle lean
Accessibility-first approach met our compliance requirements
TypeScript-native for excellent developer experience

Styling: Tailwind CSS with JIT Compilation

Design system enforcement prevented styling inconsistencies
Zero runtime cost with compile-time optimization
Development speed increased dramatically with utility classes

The Results That Matter

Few months later, our new core platform dashboard delivers:

Performance: Lighthouse scores consistently above 95
Bundle Size: 340KB initial load (32% under target)
Development Velocity: 3x faster feature delivery compared to Backstage
Team Satisfaction: Developers report significantly improved DX

The Framework Behind Our Success

Our technology selection wasn't based on gut feelings or the latest blog posts. We developed a systematic evaluation approach that any team can adapt. Here's the complete framework that guided our decisions:

Why Technology Selection Matters

The Cost of Wrong Decisions

Technical Debt: Poor initial choices compound over time, requiring expensive rewrites
Developer Productivity: Wrong tools slow down development and increase frustration
Performance Impact: Framework overhead directly affects user experience
Maintenance Burden: Some technologies require more ongoing maintenance than others
Talent Acquisition: Popular technologies make hiring easier; niche ones limit your candidate pool

The Opportunity Cost

Every technology choice has an opportunity cost. Choosing Framework A means you can't easily switch to Framework B's benefits later without significant refactoring. This makes upfront evaluation crucial.

Framework for Technology Evaluation

Step 1: Define Your Requirements

Before evaluating any technology, clearly define your project requirements. Consider both functional and non-functional requirements:

Functional Requirements

Application complexity (simple landing page vs. complex dashboard)
Feature requirements (real-time updates, offline support, etc.)
Integration needs (APIs, third-party services, legacy systems)
User interaction patterns (forms, data visualization, multimedia)

Non-Functional Requirements

Performance: Load times, runtime performance, Core Web Vitals
SEO: Search engine visibility requirements
Accessibility: WCAG compliance needs
Security: Data handling, authentication requirements
Scalability: Expected traffic and feature growth
Browser Support: Which browsers and versions to support

Team & Business Requirements

Team Skills: Current expertise and learning capacity
Timeline: How quickly you need to deliver
Budget: Development and maintenance costs
Maintenance: Long-term support capabilities
Hiring: Availability of developers with required skills

Step 2: Establish Evaluation Methodology

A systematic evaluation approach prevents bias and ensures you consider all important factors.

Data Sources for Evaluation

Internal Prototyping: Build small prototypes with each candidate technology
Community Benchmarks: Leverage existing performance comparisons and studies
Bundle Analysis: Use tools like webpack-bundle-analyzer to understand size impact
Developer Surveys: Reference Stack Overflow, State of JS, and similar surveys
Production Case Studies: Study how similar companies solved similar problems

Evaluation Criteria Framework

Create consistent criteria for comparing technologies. Here's our proven framework:

Technical Criteria:

Performance characteristics
Bundle size impact
Development experience quality
Learning curve steepness
Ecosystem maturity
Production readiness

Business Criteria:

Community support and longevity
Maintenance requirements
Talent availability
License and cost considerations
Vendor lock-in risks

Step 3: Scoring and Comparison

Frontend Framework Evaluation

When evaluating frontend frameworks, use these key criteria:

Criteria	Excellent	Good	Fair
SSR/SSG	Built-in without config	Requires setup	Manual implementation
Bundle Size	Less than 200KB typical app	200-500KB	Greater than 500KB
Dev Experience	Hot reload under 500ms, great tooling	Hot reload under 2s, good tools	Hot reload over 2s, basic tools
Learning Curve	Under 1 week for proficient dev	1-3 weeks	Over 3 weeks
Ecosystem	Over 10k stars, active maintenance	1k-10k stars, regular updates	Under 1k stars, occasional updates
Performance	Lighthouse over 90, green vitals	Lighthouse 70-90	Lighthouse under 70

Example Framework Comparison

Framework	SSR/SSG	Bundle Size	Dev Experience	Learning Curve	Ecosystem	Performance
Next.js	✅ Built-in	Medium	Excellent	Medium	Large	Excellent
Vite + React	❌ Manual	Small	Good	Low	Medium	Good
SvelteKit	✅ Built-in	Small	Excellent	Medium	Medium	Excellent
Nuxt.js	✅ Built-in	Medium	Excellent	Medium	Large	Excellent

UI Library Evaluation

For UI libraries and component systems, consider:

Criteria	Description
Bundle Impact	Effect on final bundle size
Customization	Ability to modify appearance and behavior
Component Quality	Testing, documentation, production-readiness
TypeScript Support	Level of type safety and IntelliSense
Accessibility	WCAG compliance and screen reader support
Maintenance Model	Self-managed vs. external dependency

UI Library Comparison

Library	Bundle Impact	Customization	Component Quality	TypeScript	Accessibility	Maintenance
Shadcn/ui	Minimal	Complete	Excellent	Native	Excellent	Self-managed
Material UI	Large	Limited	Excellent	Good	Good	External
Chakra UI	Medium	Good	Good	Good	Good	External
Ant Design	Large	Limited	Excellent	Good	Good	External
Mantine	Medium	Good	Good	Excellent	Good	External
Headless UI	Minimal	Complete	Good	Excellent	Excellent	External
NextUI	Medium	Good	Good	Good	Good	External
Arco Design	Large	Limited	Good	Good	Fair	External

Styling Solution Evaluation

Different styling approaches have different trade-offs:

Solution	Bundle Size	Dev Speed	Consistency	Customization	Learning Curve
Tailwind CSS	Optimized	Very Fast	Excellent	High	Medium
Styled Components	Runtime overhead	Fast	Good	High	Low
CSS Modules	None	Medium	Good	High	Low
Vanilla Extract	Zero runtime	Fast	Excellent	High	High

Advanced Evaluation Techniques

Prototype-Driven Evaluation

Build the same small application with each candidate technology:

// Example prototype requirements
const prototypeRequirements = {
  features: ["Login form with validation", "Data table with sorting", "Modal dialog", "Responsive navigation"],
  metrics: ["Time to implement", "Bundle size", "Performance scores", "Developer experience"],
};

Performance Benchmarking

Create consistent performance tests:

// Example performance test checklist
const performanceTests = {
  lighthouse: "Run Lighthouse audits on production build",
  bundleSize: "Analyze bundle with webpack-bundle-analyzer",
  loadTesting: "Test with realistic user scenarios",
  realUserMonitoring: "Measure Core Web Vitals in production",
};

Technical Debt Assessment

Evaluate long-term maintenance implications:

Update Frequency: How often does the technology release breaking changes?
Migration Path: How easy is it to upgrade or migrate away?
Community Health: Is the community growing or shrinking?
Corporate Backing: Is there sustainable funding for development?

Red Flags to Avoid

Technology Red Flags

Declining GitHub Activity: Fewer commits, closed issues, inactive maintainers
Breaking Changes: Frequent breaking changes without clear migration paths
Poor Documentation: Incomplete, outdated, or unclear documentation
Small Community: Limited Stack Overflow answers, tutorials, or hiring pool
Vendor Lock-in: Difficult to migrate away from or extract business logic

Team Red Flags

Skills Mismatch: Technology requires skills your team doesn't have and can't acquire quickly
Analysis Paralysis: Spending too much time evaluating instead of building
Shiny Object Syndrome: Choosing based on novelty rather than suitability
Not Invented Here: Rejecting proven solutions in favor of building custom tools

Making the Final Decision

Decision Matrix Template

Create a weighted decision matrix:

| Criteria       | Weight | Option A | Score A | Option B | Score B |
| -------------- | ------ | -------- | ------- | -------- | ------- |
| Performance    | 25%    | 8/10     | 2.0     | 6/10     | 1.5     |
| Dev Experience | 20%    | 9/10     | 1.8     | 7/10     | 1.4     |
| Learning Curve | 15%    | 6/10     | 0.9     | 8/10     | 1.2     |
| Ecosystem      | 20%    | 9/10     | 1.8     | 7/10     | 1.4     |
| Bundle Size    | 10%    | 7/10     | 0.7     | 9/10     | 0.9     |
| Maintenance    | 10%    | 8/10     | 0.8     | 6/10     | 0.6     |
| **Total**      | 100%   | -        | **8.0** | -        | **7.0** |

Risk Assessment

For your top choice, identify and plan for risks:

Technical Risks

Performance Issues: Mitigation strategies if performance doesn't meet requirements
Scalability Limits: Plans for handling growth beyond current capabilities
Security Vulnerabilities: Process for handling security updates

Business Risks

Technology Abandonment: Exit strategy if the technology is discontinued
Talent Shortage: Hiring and training plans for required skills
Budget Overruns: Contingency plans if development takes longer than expected

Implementation Best Practices

Gradual Adoption Strategy

Don't migrate everything at once:

Proof of Concept: Build a small, non-critical feature
Pilot Project: Choose a bounded project for full implementation
Lessons Learned: Document what worked and what didn't
Gradual Rollout: Apply learnings to larger projects
Full Migration: Only after proving success at scale

Document your decisions and reasoning:

Architecture Decision Records (ADRs): Formal documentation of technology choices
Runbooks: Operational procedures for deployment and maintenance
Training Materials: Help team members become productive quickly
Migration Guides: Plans for future technology updates

Monitoring and Validation

Continuously validate your technology choices:

Performance Monitoring: Track real-world performance metrics
Developer Productivity: Measure development velocity and satisfaction
Error Rates: Monitor for technology-related issues
User Experience: Gather feedback on application performance and usability

Future-Proofing Your Stack

Stay Informed

Technology Radars: Follow ThoughtWorks Technology Radar and similar resources
Community Trends: Monitor GitHub stars, npm downloads, and survey results
Conference Talks: Attend conferences to learn about emerging patterns
Industry Reports: Read State of JS, Stack Overflow surveys, and framework-specific reports

Build for Change

Modular Architecture: Design systems that allow swapping components
Abstract Business Logic: Keep business rules separate from framework code
Standard Interfaces: Use common patterns that work across technologies
Comprehensive Testing: Tests make refactoring and migration safer

Conclusion

Choosing frontend technologies is both an art and a science. While systematic evaluation helps avoid major pitfalls, there's no perfect choice for every situation. The key is to:

Understand your requirements deeply before evaluating options
Use consistent evaluation criteria to compare fairly
Build prototypes to validate assumptions
Document your decisions for future reference
Plan for change because technology evolves quickly

Remember that the "best" technology is the one that best serves your users, your team, and your business goals. Don't chase the latest trends—choose technologies that solve real problems and enable your team to deliver value consistently.

The evaluation framework presented here has helped us make confident technology decisions for production applications. Adapt it to your context, and remember that good enough today often beats perfect tomorrow.

This article is provided as a general guide for general information purposes only. It does not constitute advice. CECG disclaims liability for actions taken based on the materials.