Selise Blocks

Posted on Jul 2 • Originally published at selisegroup.com

Blocks Cloud OS: Solving Developer Experience While Stakes Are Rising

#devrel #cloud #platformengineering #ai

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 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, and 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 database

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've been given the ergonomics to build your core features.

Is this approach for everyone? No. If you need a non-secure, non-enterprise app, 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's 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:

Task	Traditional Timeline
Infrastructure provisioning	3–5 days
CI/CD pipeline configuration	2–3 days
Authentication implementation	3–5 days
Observability setup	2–3 days
Environment management scripts	1–2 days
Total before writing business logic	2–3 weeks

Now here's Blocks Cloud:

Task	Blocks Cloud Timeline
Create project in Portal	3 minutes
Download Construct	2 minutes
Configure auth settings	15 minutes
First deployment	25 minutes
Total before writing business logic	< 1 hour

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 to call LLMs, and 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:

What You Get	What You Don't Need to Build
Authentication flows (login, register, password reset, MFA)	Auth UI components
Role-based access control	Permission logic
API client configured for backend services	HTTP interceptors and token handling
Localization support	i18n infrastructure
Responsive, modern UI components	Design system from scratch
Best practices baked in	Code review debates about patterns

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.

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.

Who This Is Actually For

Let's 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, and 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 and different tech stacks, and need to keep 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 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.

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.

DEV Community