A developer-to-developer look at platform engineering done right .

The Problem: death by a thousand configurations 

Here’s a number that should bother you: 50% of developers lose more than 10 hours per week to tasks that have nothing to do with building their actual product. 

That’s not from some random survey. It’s from Atlassian’s 2025 State of Developer Experience report—the same report that found 99% of developers are saving time with AI tools. Read that again. We’re all using AI assistants, we’re all supposedly more efficient, and yet half of us are still bleeding over 10 hours a week to… what exactly? 

Finding documentation. Context switching. Setting up environments. Configuring authentication for the fifteenth time. Debugging deployment pipelines. Searching for that one config file that someone modified three months ago. 

These aren’t hard problems. They’re solved problems. Authentication? Solved decades ago. Deployment? We have CI/CD. Observability? Plenty of tools. And yet, every new project feels like assembling the same IKEA furniture from scratch, without the manual, in the dark. 

The problems are solved. But they’re not solved for you, not until you spend days or weeks wiring everything together. 

This is the developer experience paradox: we have better tools than ever, but we spend more time than ever not coding or prompting to code. 

The dilemma every developer faces 

When starting a new project, you face the same painful choice: 

Option A: build everything yourself 

• Full control over every decision. 

• Choose the exact libraries and patterns you prefer. 

• Spend days on authentication, deployment pipelines, logging infrastructure, and environment configuration before writing your first line of business logic. 

• Own all the maintenance burden forever. 

• Hope you didn’t make security mistakes. 

Option B: use a platform 

• Get to production fast. 

• Someone else handles the infrastructure headaches. 

• Accept vendor lock-in. 

• Externalize your data to third-party environments. 

• Lose flexibility when you inevitably need something the platform doesn’t support.

It’s the classic trade-off: expensive sovereignty versus convenient dependency.

What if these weren’t the only options? 

What if there was a middle path—one where you get the speed of a platform but retain control over your data and architecture? Where the “solved problems” are actually solved, but you’re not locked into someone else’s vision of how software should work? 

That’s the question SELISE asked when building Blocks Cloud. 

What is Blocks Cloud? 

Let’s skip the marketing speak. Blocks Cloud is a developer platform that provides: 

• A ready-to-use React boilerplate (called Construct) pre-wired to backend services 

• The same boilerplate in other languages (public soon or upon request) 

• Enterprise authentication and authorization with every grant type you’d actually need 

• Deployment pipelines that work out of the box including SAST, SCA, DAST 

• Built-in observability (logs, metrics, traces) 

• AI agent capabilities you can embed with a script tag 

• Localization with AI-powered translation 

• Fully managed blob storage and a nosql data base 

The philosophy is simple: you should be configuring behavior, not writing glue code. 

Here’s the workflow: 

Configure via Portal → Download Construct → Build Your Logic → Deploy → Observe 

That’s it. No Terraform scripts. No Kubernetes manifests. No hours lost configuring CloudWatch or setting up Datadog. The infrastructure decisions are made. You have been given the ergonomics to build your core features. 

Is this approach for everyone? No. If you need a non-secure, non-enterprise app, perhaps this may not be for you. But for the vast majority of applications? This model eliminates weeks of setup time. 

How Blocks Cloud solves core DX problems 

Let me walk through the specific friction points that eat those 10+ hours per week, and how Blocks Cloud addresses each one. 

Zero-to-production in hours, not weeks 

Here’s what a traditional project setup looks like: 

Now here’s Blocks Cloud: 

The difference isn’t incremental, it’s categorical. You’re not waiting days to see if your architecture decisions work. You’re seeing results in minutes. 

Deployment options are straightforward: 

• Automatic: Push to a mapped branch, deployment triggers automatically. 

• Manual: Click “Deploy” when you’re ready. 

Both options provide real-time logs so you can watch the process. If something fails, you know immediately and can see exactly why. No more “deploy and pray.” 

Authentication Without the Headache 

How many times have you implemented authentication? How many times have you debugged token refresh logic, session handling, or OAuth redirect flows? 

Authentication is one of those “solved yet unsolved” problems. We all know how it works. We’ve all done it before. And yet it still takes days to get right for each new project. 

Blocks Cloud treats auth as configuration, not code: 

Supported grant types: 

• Email/Password with configurable token lifetimes. 

• Social SSO: Google, Microsoft, GitHub, LinkedIn, X, etc. 

• External IdP: Keycloak, Okta, Auth0, Azure. 

• Client Credentials for service-to-service auth. 

Security features (Toggle-enabled): 

• MFA with authenticator apps. 

• CAPTCHA integration. 

• Account lockout policies. 

• Session management controls. 

Want to require MFA only for your users? That’s a configuration option. Need to integrate with your existing Keycloak instance? Add the connection details in the Portal.  

The Construct boilerplate handles all the frontend flows—login screens, password reset, MFA verification—out of the box. Your job is deciding what authentication should look like, not how to implement it. 

AI integration that actually works 

AI has become an expectation, not a differentiator. Your users expect conversational interfaces, intelligent assistance, and natural language interactions. 

Building this yourself means: 

• Choosing and integrating LLM providers 

• Implementing RAG pipelines for domain knowledge 

• Building conversation management 

• Creating guardrails against prompt injection 

• Handling rate limits, token costs, and failover 

• Designing and deploying chat interfaces 

Blocks Cloud approaches this differently. The Agents system lets you configure AI capabilities through the Portal: 

Agent configuration: 

• Choose from templates (Customer Service, IT Support, HR Assistant) or create custom agents 

• Select your LLM and configure parameters (temperature, max tokens, system prompts) 

• Upload knowledge base documents (PDFs, DOCs, text files) 

• Define guardrails: PII detection, blocked patterns, risk thresholds 

Knowledge base integration: 

• Upload files directly or crawl URLs 

• Add Q&A pairs for precise answers 

• Test retrieval before deployment—see exactly what your agent will find for specific queries 

MCP support: 
What makes this particularly interesting is the built-in MCP (Model Context Protocol) support. Connect to external tools and APIs, expose them to your AI agents, and suddenly your chatbot can actually do things—check order status, create tickets, query databases. 

Embedding: 

<script   

  src=”https://gpt.seliseblocks.com/embed.js”   

  data-widget-id=”your-widget-id”   

  data-widget-type=”chat”   

  data-project-key=”your-project-key”>   

</script> 

One script tag. That’s the integration. Your AI-powered chatbot is now embedded in your application, connected to your knowledge base, protected by your guardrails, using your chosen LLM. 

Is this as flexible as building custom? No. Can you achieve 95% of what most applications need with effectively zero ML expertise? Yes. 

Custom AI integrations 

What about custom AI use cases? Use the APIs provided by us to call LLMs, the data gateway to store the data generated from these use cases. 

Observability that’s ready when you are 

Observability often gets treated as an afterthought. You build the app, deploy it, and then scramble to add logging when something breaks in production. 

Blocks Cloud flips this. The Observability / LMT stack (Logs, Metrics, Tracing) is built in from day one: 

Logs: 

• Real-time log viewing with date and level filtering 

• AI-powered log analysis for quick pattern identification 

• Both application and deployment logs in one place 

Distributed tracing: 

• Trace requests across services 

• Visualize timing and dependencies 

• Correlate traces with logs via trace IDs 

Metrics: 

• Service-level performance monitoring 

• Usage patterns and trends 

• Automatic collection via OpenTelemetry integration 

The key insight here is that observability isn’t something you should have to set up. It should just be there, working, from the first deployment. When your first user reports an issue, you shouldn’t be thinking “let me add some logging”—you should be looking at logs, traces, and metrics that already exist. 

The Construct advantage 

At the heart of Blocks Cloud is Construct—a pre-built React application that comes pre-wired to all platform services. 

What this means practically: 

When you clone Construct, you’re not starting from zero. You’re starting from a working application with authentication, routing, and API integration already functional. 

This is what the industry calls a “paved road”—a golden path that incorporates best practices without requiring you to be an expert in every aspect of the stack. You can deviate from the paved road when needed. But for most use cases, you don’t need to. 

The time savings compound. Instead of spending the first month on infrastructure and basic flows, your team is building features in week one. 

Configuration, not code: the philosophy 

There’s a mental model shift that Blocks Cloud embodies: configuration over code for solved problems. 

Here’s what I mean. Some problems are genuinely hard: 

• Your specific business logic 

• Domain modeling 

• Performance optimization for your use case 

• User experience design 

These require code. They require your expertise and attention. 

Other problems are hard but generic: 

• Authentication 

• Authorization 

• Deployment pipelines 

• Logging infrastructure 

• Environment management 

These also require expertise—but not your expertise. They’ve been solved thousands of times. The expertise is in configuring them correctly, not reimplementing them. 

Blocks Cloud’s Portal is designed around this distinction. It’s a configuration interface for the generic problems, freeing you to write code for the specific ones. 

Examples: 

Environment Management 

• Development, Testing, Staging, UAT, Production environments pre-configured 

• Branch mapping: dev → Development, main → Production 

• Environment migration via visual interface: select source, select target, click migrate 

Email Templates 

• Configure SMTP settings once 

• Design email templates in a visual editor 

• Trigger emails via API or automation—no email infrastructure code needed 

Localization 

• Define keys and default translations 

• One-click AI translation to all configured languages 

• Import/export in JSON, CSV, or Excel 

• Translations publish instantly to your frontend 

Each of these would be a multi-day effort to implement from scratch. As configuration, they’re measured in minutes. 

Who this is actually for 

Let me be direct about who benefits most from this approach. 

Teams building enterprise web applications 

If you’re building internal tools, B2B SaaS, or customer-facing web applications with: 

• Complex authentication requirements (SSO, MFA, multiple identity providers) 

• Multi-environment deployment needs 

• Localization requirements 

• Standard CRUD plus some intelligence 

This is the sweet spot. The platform handles exactly what you need without forcing complexity you don’t. 

Organizations under timeline pressure 

When you have aggressive deadlines, spending three weeks on infrastructure setup isn’t an option. Blocks Cloud compresses that to hours. Your team ships features in week one instead of month two. 

Teams without dedicated DevOps 

Not every team has infrastructure expertise. With Blocks Cloud, you don’t need deep knowledge of Kubernetes, Terraform, or cloud provider quirks. The deployment pipeline works. The observability works. You focus on your application. 

Companies adding AI to existing products 

If your roadmap includes “add conversational AI” but your team doesn’t have ML expertise, the Blocks AI & Agents system provides a practical path. Configure, test, embed. No model training, no RAG pipeline development, no infrastructure for GPU inference. 

Companies with distributed teams 

If you develop across the globe 24/7 with various teams, different tech-stacks and you need to keep the quality in check. Blocks is built by teams who shipped high value enterprise apps for Banks, Healthcare and Insurance companies over many years keeping quality standards in mind from the first line of code written. 

The trade-offs (yes, there are some) 

I’d be doing you a disservice if I pretended there were no trade-offs. There are always trade-offs. 

Platform dependency 

You’re depending on Blocks Cloud for core services. If you later decide you need a completely custom authentication system or a different UI framework, migration has costs. 

Mitigation: Blocks Cloud can be deployed on your own infrastructure for organizations with strict requirements. The platform is open, free of cost, and you can maintain it yourself. 

React coupling 

Construct is React-based. If your team is committed to Vue, Angular, or another framework, you lose some of the boilerplate advantages. 

Reality check: You can still use Blocks Cloud backend services via APIs—you just write your own frontend, request constructs in your language or just wait for more constructs to be released publicly. 

Configuration constraints 

Configuration is powerful but finite. If you need authentication behavior that isn’t supported by the configuration options, you’re either requesting a feature or working around the system. 

The question: For the vast majority of use cases, are the configuration options sufficient? In my assessment: yes. 

Is Blocks Open Source? Yes. Can you contribute your required enhancements upstream? You’re more than welcome to contribute! 

Learning curve 

There’s a learning curve for the Portal and understanding of Construct’s structure. It’s not steep, but it’s not zero. 

Counter-point: Compare this to the learning curve of Kubernetes, Terraform, CloudFormation, and the various SaaS and PaaS tools you’d otherwise need to integrate. 

Final thoughts 

Developer Experience isn’t only about making developers happy (though that’s nice). It’s about recognizing that developer time is your most expensive resource, and every hour spent on solved problems is an hour not spent on differentiation. 

The statistics are clear: 

• 50% of developers lose 10+ hours weekly to non-coding tasks 

• Context switching destroys flow state and productivity 

• “Solved” problems keep getting re-solved, project after project 

Blocks Cloud represents one answer to this problem—not the only answer, but a coherent one. It takes the position that authentication, deployment, observability, and basic AI integration shouldn’t require custom development. They should be configuration options. 

Does this mean giving up some flexibility? A little bit. Does the trade-off make sense for most enterprise applications? I’d argue yes. 

The philosophy is simple: Focus on building features, not wiring infrastructure. 

If you’re tired of re-implementing authentication, tired of debugging deployment pipelines, tired of spending weeks on setup before writing business logic—this approach deserves consideration. 

The future of developer experience isn’t more tools. It’s better integration. It’s platforms that understand the full development lifecycle and optimize it end-to-end. It’s the recognition that developers are builders, not plumbers. 

Stop wiring. Start building. 

Ready to explore? Visit cloud.seliseblocks.com to get started, or check out the documentation for a deeper dive.