Not a "community edition." Not a stripped-down version with the good parts held back. The same code that runs our shared platform, the same code a graduating customer forks and deploys on their own infrastructure. All of it, public, today.

Why​

We built 23blocks because backend work is repetitive. Every product needs auth, needs file storage, needs some kind of CRM, needs forms. We got tired of building it from scratch, so we built it once, well, and reused it — first for ourselves, then for customers.

Somewhere in that process we had to decide what we were actually selling. For a while the honest answer was "the code," and that's a bad business to be in if you're small. Code copies for free. A well-funded competitor, or frankly a good engineering team with three weeks to spare, can replicate a backend module. What they can't replicate overnight is the part we've actually spent years on: keeping 20+ services patched, monitored, backed up, and running at 2am when something breaks that isn't your problem to fix.

So we stopped pretending the code was the moat. It isn't. Running it well is.

Once we admitted that, open-sourcing the blocks stopped being a risk and started being obvious. It's a better trust signal than any sales page: you can read the auth block's token-issuance logic before you decide whether to trust it with your users' sessions. You can see exactly what a webhook payload looks like before you build against it. You can fork it and never talk to us again if that's what you need. We'd rather earn the business that follows from that than protect a moat that was never as solid as it looked.

There's a practical reason too. We're a small team. We cannot out-market or out-hire the platforms with venture-scale marketing budgets. What we can do is be the most honest, most inspectable option in the category, and let the code speak for itself.

What's actually released​

All 20+ blocks, under the Apache License 2.0 — rolling into public repositories starting today.

Why rolling, not all at once? Every repo passes a security gate before it flips public: full-history secret scanning (gitleaks, entropy detection on), credential rotation, and a clean-snapshot rebuild. The first blocks are live now; the rest follow, one by one, as each comes back clean. We'd rather open-source slowly than leak a tenant's key quickly. Track the rollout live:

• Auth — sessions, tokens, SSO, permissions
• CRM — contacts, pipelines, activity tracking
• Files — storage, access control, delegated uploads
• Forms — schemas, surveys, appointments, public forms, subscriptions
• Content — posts, categories, comments, series
• Products — catalog, search, visual/object-detection search
• Search, Companies, Onboarding, Rewards, Sales, Wallets, Geolocation, University, Real-time/conversations, Jarvis (AI/agents), and the rest of the catalog.

Every block follows the same environment-variable contract we've always built to: no hardcoded hosts, no baked-in secrets, health-check endpoints, the works. That's not new — it's what already lets customers graduate off our shared platform onto their own infrastructure without a rewrite (more on that in our companion post on graduating to your own infrastructure). Open-sourcing the code is really just extending a portability guarantee we already honored in practice to something you can now git clone and verify yourself, before you've ever signed up for anything.

We're publishing real READMEs, not placeholder ones — how to run each block locally, what its environment variables mean, what its API surface looks like. We know from experience that an open-source repo nobody can actually run is worse than no repo at all.

What stays paid — and why that's the honest model​

Open source doesn't mean we've decided to work for free, and it doesn't mean we think you should have to run this yourself if you don't want to. Three ways to use 23blocks, and only two of them cost money:

1. Shared Platform (SaaS). Free tier to start, pay-as-you-grow after. We run the infrastructure, patch it, monitor it, back it up, and answer the pager. You get an API key and you're building in minutes. This is where most people should start.

2. 23blocks in a Box. We deploy and maintain the same blocks on your cloud account — your AWS, your GCP, your Azure. You get dedicated infrastructure, your own compliance boundary, your own data residency, and we still carry the operational weight. This is what "graduating" looks like for a lot of customers: same platform, your infra, us still on call.

3. Deployment recipes. If you want to run it entirely yourself — no relationship with us at all — the recipes and docs are there. Docker Compose, Kubernetes/Helm, Terraform, whatever your stack looks like. This is the true "just take the code" path, and now it's fully available, not gated behind a sales call.

The through-line: you never pay for the software. You pay for running it — either because we run it for you (options 1 and 2), or you don't pay us at all and run it yourself (option 3). That's the whole business model, said plainly, because we'd rather you understand it than have to trust a euphemism.

We call this open-core, and we know the term gets used to describe a lot of bait-and-switch. Ours works differently: there is no artificial feature gate in the open-source code. Nothing is crippled to force you onto a paid tier. What you pay for is genuinely operational — infrastructure, monitoring, on-call, upgrades — the stuff that's real work regardless of who's doing it.

What this means if you're already a customer​

Nothing breaks. Nothing changes about your bill, your API keys, your uptime, or your support channel. If you're on the shared platform today, you're still on the shared platform today, still talking to the same team, still getting the same SLA.

What does change: you now have the option to look at exactly what's running under you, and — if you ever want to — to graduate to your own infrastructure with the code already public and forkable, rather than waiting on us to hand you an export. We've done this migration for real customers already; one reference case moved 11 blocks across 4 consumer surfaces in a single reversible maintenance window with zero code changes. We wrote up what that actually involved, sequences and JWT issuers and all, because we think the honest version of that story is more convincing than a marketing page would be.

If you're on 23blocks in a Box already, this doesn't change your contract either — you're already running dedicated infrastructure we maintain. The code you're running was always yours to fork; now the rest of the world can see it too.

How to start​

• Just want to build? Sign up for the Shared Platform — free tier, API key in minutes.
• Want dedicated infrastructure, still maintained by us? Ask about 23blocks in a Box.
• Want to run it yourself, no relationship required? The repos and deployment recipes are public, starting today.
• Curious what's actually in the box? Browse the block documentation — it's the same docs our own team uses.

We think this is a better business than the one we'd have if we kept the code closed. We also think it's a more honest one. If you build something with these blocks, or find something worth fixing, we'd like to hear about it — join the Slack community or open an issue on any repo.

— Juan Peláez, Founder & CTO

Full reference: 23blocks in a Box — the engineering guide.

The setup​

The customer was running 11 blocks (auth, files, forms, CRM, products, search, and others) on our shared, multi-tenant platform, consumed by 4 separate surfaces — a public web app, an admin console, a mobile client, and an internal ops tool. They wanted dedicated infrastructure in their own AWS account: their own compliance boundary, their own scaling, their own on-call, no shared-tenant blast radius.

The property that made this tractable at all: every block is fully configured by environment variables. No hardcoded hostnames, no baked-in secrets, the same container image runs on shared or dedicated infrastructure unchanged. Graduating a block isn't a code change — it's a question of where the container runs and what URLs the consuming apps point at.

Six phases, four of them invisible to users​

1. Fork. Each block forked into the customer's own org. No CI secrets or shared-platform config travel with it — just the code, which they now own outright and can git pull upstream on their own schedule.

2. Build. The fork's own pipeline builds images, pushes to the customer's registry. Their build, their artifacts.

3. Provision. Dedicated single-tenant footprint stood up in their AWS account — same architecture as shared 23blocks, sized for one tenant: load balancer, container services, a Postgres instance with one database per block, Redis, S3-equivalent storage, TLS.

4. Migrate data. Per-block tenant schemas copied whole; control rows filtered to the tenant; sequences advanced to MAX(id); row parity verified table by table.

Phases 1–4 happened over roughly two weeks with zero user-facing impact. Phases 5 and 6 — cutting over consumers and verifying — happened inside a single maintenance window.

The cutover window​

The flip itself is designed to be boring, because boring is reversible and exciting is not.

1. Freeze. All 4 surfaces stop writing — SPAs show a maintenance page, backends go process-down. One very-low-write internal tool took an accepted no-freeze.
2. Final delta re-sync. Bring the dedicated database to an exact, current copy of the shared tenant. Reset sequences again. Verify parity again.
3. URL-only flip. Every consumer's only change is a base URL: *.api.us.23blocks.com → *.api.us.<customer-domain>. Same API key, valid on both sides. No redeploy of application logic, no new secrets to distribute.
4. New major version per app. Each of the 4 surfaces cut a new major version whose only diff is the URLs. New major = own infrastructure; previous major = shared. The version number alone now tells you where an app points, and rollback is "redeploy the previous major" — no rebuild required.
5. Verify behind the maintenance page. Auth sign-in and token validation, the full read path, one real write — checked before anyone is let back in.
6. Confirm zero shared traffic. Post-flip, the shared load balancer showed zero requests carrying that tenant's API key, across all 11 blocks. That's the actual definition of "done" — not "we flipped the switch," but "we can see nobody's using the old path anymore."

Total user-facing disruption: one maintenance window. Rollback stayed armed the entire time because the shared-cloud data was never mutated during the process — flipping URLs back is always clean.

Five lessons that are now baked into the tooling​

These weren't known in advance. They were found the hard way, on real graduations, and are now checks the migration tooling runs automatically.

1. A data re-sync silently reverts infra-config​

The tenant's control row carries infrastructure settings alongside business data — the auth JWT issuer URL, the API base URL, webhook URLs — and on shared, all of them point at shared-cloud hosts. A naive re-sync overwrites the customer's own values with the shared ones.

This is exactly what happened: after a delta re-sync, the issuer URL silently reverted, the customer's auth service started minting tokens with the shared issuer, and every login started failing validation on the new infrastructure. Nothing was down; auth just rejected its own freshly-issued tokens.

Fix: the migration now captures the target's infra-config columns before every re-sync and restores them immediately after. Data moves; infra config doesn't get overwritten by it.

2. Env-var-driven frontends don't flip when you deploy code​

One of the four surfaces was a Next.js site with NEXT_PUBLIC_* API URLs baked in at build time from the hosting console's environment variables — not read from the repo at runtime. Shipping new application code did nothing to the URLs; the console env vars had to be updated and the site rebuilt before it would talk to the new infrastructure.

The team's other surfaces, Angular apps carrying config in environment.prod.ts, didn't have this trap — their config is compiled into the code artifact itself, so a new build picks it up automatically. The lesson isn't "one pattern is better," it's: know which config model each of your surfaces uses before the cutover window, because the remediation step is different for each, and you don't want to discover that live.

3. Postgres sequences don't travel with pg_dump​

pg_dump / COPY moves rows. It does not move sequence state. The first insert against a freshly copied table collides on a primary key that already "exists" as far as the sequence's internal counter is concerned, because that counter reset to whatever it was in the dump, not to MAX(id).

This is easy to miss in a dry run with low write volume and then bite hard in production the moment real traffic resumes writes. Every serial sequence gets explicitly advanced to MAX(id) after every copy — dry run or real cutover, no exceptions.

4. JWT issuer identity must match the validating host, exactly​

If a token's issuer claim doesn't match the host validating it, the login bounces — not because credentials are wrong, but because the token was minted for a different identity than the one checking it. This surfaced in the same incident as lesson #1, but it's worth stating as its own rule because it applies any time issuer and validator can get out of lockstep — for instance, if backend services can't all flip in the same instant.

Mitigation for staged rollouts: a dual-trust issuer window — accepting both the old and new issuer for a bounded period — smooths a cutover where not every service flips atomically.

5. Config drift across blocks is real and it will bite you at the worst time​

Values that are supposed to be identical across every block's database — the tenant's API key, shared webhook URLs — tend to drift over the life of a tenant, usually from manual hotfixes applied to one block and never backported to the others. Verify these are consistent across every block before you plan a cutover, not during it. Discovering a mismatched API key mid-maintenance-window turns a 30-minute flip into a 3-hour one.

Why we're writing this down publicly​

None of this is proprietary insight worth hoarding — it's the kind of thing every team doing a data-plane migration eventually rediscovers, usually at 2am. We'd rather you read it here first. It's also, not coincidentally, the same reason we're open-sourcing the blocks themselves: the code and the operational knowledge around it are both more valuable shared than protected, and we'd rather compete on doing this well than on being the only ones who know how.

If you're evaluating a similar move, the full technical reference — the complete environment-variable contract, health-check endpoints, and the six-phase process in more detail — is at 23blocks in a Box.

Edge Architecture Overview​

Every API request to 23blocks flows through our global edge network:

Your App → CloudFront Edge → Lambda@Edge → Service API

CloudFront Global Edge​

Requests hit one of 400+ CloudFront edge locations worldwide, ensuring sub-50ms latency regardless of where your users are located.

Lambda@Edge Routing​

Our Lambda@Edge function handles intelligent routing:

1. API Key Validation - Verifies your API key instantly
2. Environment Detection - Routes to staging or production based on key prefix
3. Service Routing - Directs traffic to the correct service backend

Per-Service URL Pattern​

Each 23blocks service has its own dedicated URL:

Environment Routing via API Keys​

One of the most powerful aspects of our architecture is API key-based environment routing. Use the same URL for all environments - your API key determines where traffic goes:

Benefits​

• Simpler Configuration - No environment-specific URLs to manage
• Safer Deployments - Just swap API keys, not URLs
• Consistent Testing - Same code paths in dev and production

Example Usage​

import { create23BlocksClient } from '@23blocks/sdk';

// Staging
const stagingClient = create23BlocksClient({
  urls: { authentication: 'https://auth.api.us.23blocks.com' },
  apiKey: 'pk_test_abc123'  // Routes to staging
});

// Production
const productionClient = create23BlocksClient({
  urls: { authentication: 'https://auth.api.us.23blocks.com' },
  apiKey: 'pk_live_xyz789'  // Routes to production
});

Monitoring Infrastructure​

Every service is monitored 24/7 with:

• Prometheus - Metrics collection and alerting
• Grafana - Real-time dashboards and visualization
• Loki - Centralized log aggregation
• Custom Health Checks - Per-service availability monitoring

Our SRE team receives alerts within 30 seconds of any service degradation.

Health Check Endpoints​

Each service exposes a health check endpoint:

GET https://{service}.api.us.23blocks.com/health

Response:

{
  "status": "healthy",
  "service": "auth",
  "version": "2.4.1",
  "timestamp": "2026-01-20T10:30:00Z"
}

AWS Infrastructure​

Behind the scenes, each service runs on:

• Application Load Balancers - SSL termination and routing
• ECS Fargate - Serverless container orchestration
• RDS Aurora - Multi-AZ PostgreSQL databases
• ElastiCache - Redis caching layer
• S3 - Durable object storage

All infrastructure is multi-AZ within the US East region, with automatic failover and daily backups.

What This Means for You​

1. Faster APIs - Edge routing reduces latency globally
2. Simplified Code - One URL per service, environment via API key
3. Enterprise Reliability - Multi-AZ, auto-scaling, 24/7 monitoring
4. Zero DevOps - We handle all infrastructure management

Getting Started​

Update your SDK configuration to use the new per-service URLs:

import { create23BlocksClient } from '@23blocks/sdk';

const client = create23BlocksClient({
  urls: { authentication: 'https://auth.api.us.23blocks.com' },
  apiKey: process.env.BLOCKS_API_KEY  // pk_test_* or pk_live_*
});

Check out the Infrastructure Documentation for more technical details.

Questions? Join our Slack community or reach out to support@23blocks.com.

Case

To go around that unique build file for all branches, we are using variables and if instructions, we ended up having a config like this for one of our projects.

Solution

frontend:
phases:
build:
commands:    
- if [ "${AWS_BRANCH}" = "production" ]; then ng build --configuration=production --prod --build-optimizer; fi
- if [ "${AWS_BRANCH}" = "stage" ]; then ng build --configuration=stage --prod --build-optimizer; fi

this way we can have multiple environments, with different build instructions and different URLs, from multiples branches, using only one Amplify configuration.

Now, that works great on a single account environment or during Proof of Concepts, once is a real project, we would need different accounts for each environment, but that’s for another day.

Do you have an idea and want to make a prototype to see if it is functional or sustainable over time? Then, 23blocks is the best solution that you will find to carry out this development with less effort and investment.

Each of our blocks is a combination of Software, Infrastructure, and Services, which are available as API Microservices. According to industry standards, these are hosted in a highly available cloud, ready for production and use.

Making the decision to start a software project can be complicated and intimidating. So, contact us at info@23blocks.com to receive free assistance from our software experts and get started on your idea.

There is a better way to build apps and platforms —the #23blocksway.

This post presents a solution to that scenario.

Case

Our EC2 Instance has a default website on port 80 and 2 or more apps on port 80 but with different host headers (ie: aka.mydomain.com, afa.mydomain.com, etc), so when it is time to set up the Target Group Health Check we need a solution to how to monitor each service (or app) instead of the default NGINX site.

Solution

We ended up changing our default NGIX website (etc/nginx/sites-available/default) by including the following segment:

        location /aka {
                proxy_set_header Host aka.mydomain.com;
                proxy_pass http://127.0.0.1/health;                
        }

        location /afa {
                proxy_set_header Host afa.mydomain.com;
                proxy_pass http://127.0.0.1/health;
        }

Therefore, on each Target Group, we can use on the path of the Health Check “/aka” and in the other Target Group “/afa”. We are doing an NGINX redirect and adding the host header, the health route is a health check page on all our applications that returns 200 and some details of the status of our apps and services.

Now, Our EC2 instance running multiple NGINX apps or services can be a target on both Target Groups and the health check will do its job if one of the services is down sending requests to any other available targets.

Do you have an idea and want to make a prototype to see if it is functional or sustainable over time? Then, 23blocks is the best solution that you will find to carry out this development with less effort and investment.

Each of our blocks is a combination of Software, Infrastructure, and Services, which are available as API Microservices. According to industry standards, these are hosted in a highly available cloud, ready for production and use.

Making the decision to start a software project can be complicated and intimidating. So, contact us at info@23blocks.com to receive free assistance from our software experts and get started on your idea.

There is a better way to build apps and platforms —the #23blocksway.

It is just one in a long and depressing history of software bugs. Most IT experts agree that failures happen much more often than they should. Furthermore, losses are universally free from prejudice: they occur in all countries, large and small companies, in commercial, non-profit, and government organizations, and regardless of your status or reputation. In terms of the taxpayer and shareholder money wasted, business and social costs of these failures and the investments that cannot be made run into billions of dollars a year.

The problem is only getting worse the more IT is used. According to a 2017 Project Management Institute (PMI) report, 14 percent of IT projects fail. However, that number only represents the total number of failures. Of the projects that did not die outright, 31 percent did not meet their targets, 43 percent exceeded their initial budgets, and 49 percent fell behind.

Figure 1 – Estimated percentage of failures in IT projects The biggest tragedy is that software failures are predictable and avoidable for the most part. But, unfortunately, most organizations do not view failure prevention as an urgent matter, even though that vision risks damaging the organization and, in some cases, even destroying it. Understanding why this attitude persists is not just an academic exercise; it has enormous implications for business and society.

THE SOFTWARE IS EVERYWHERE. It’s what allows us to get cash from an ATM, make a phone call, and drive our cars. A typical cell phone now contains around 2 million lines of software code.

The amount and type of technology investments can vary between industries and sectors. For example, the average business spends nearly 4%t of revenue on information technology, and those heavily reliant on IT, such as finance companies, spend more than 7% on IT. In other words, IT is now one of the most significant corporate expenses outside of employee costs. Much of that money goes to hardware and software upgrades, software license fees, and others. But a large part goes to new software projects to create a better future for the organization and its customers.

Figure 2 – Causes of IT project failures It is not uncommon to think that when a software project fails, it jeopardizes the prospects of an organization. However, if the flaw is big enough, it can steal the company’s entire future.

Around the world, it’s hard to say how many software projects fail or how much money is wasted as a result. However, if you define failure as the total abandonment of a project before or shortly after delivery, and if you accept a conservative 5% failure rate, billions of dollars are wasted each year on faulty software.

Of course, those billions do not reflect projects that exceed their budgets, which is the case with most projects. Nor does it reflect projects delivered late, which is the majority. It also doesn’t factor in the opportunity costs of starting over once a project is abandoned or the expenses of bug-ridden systems that must be repeatedly reworked.

There’s also the cost of litigation from customers suing vendors over poorly implemented systems. When you add up all these additional costs, the annual tab for failed and problem software runs conservatively between $ 60 billion and $ 70 billion in the United States alone.

But why do projects fail so often? Among the most common factors:

Unrealistic or disjointed project goals Inaccurate estimates of necessary resources Badly defined system requirements Poor project status report Unmanaged risks Inadequate communication between clients, developers, and users. Use of immature technology The inability to handle the complexity of the project. Sloppy development practices Bad project management Stakeholder policy Commercial pressures

Figure 3 – IT investment percentage based on revenue. Most failures, however, can be attributed to a combination of technical, project management, and business decisions. Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure.

The earlier the omission is detected and corrected, the better. It is like knitting a sweater. If you spot a missing stitch right after you, do it, you can untangle some thread and move on. But if you don’t catch the mistake until the end, you may need to unravel the entire sweater to redo that stitch.

Suppose software developers do not detect its omission until the final test of the system (or worse, until after the system has been implemented). Then, the costs incurred to correct the error are likely to be many times greater than if they had detected it while still working on the initial sales process.

And unlike a missing stitch on a sweater, this problem is much more challenging to identify; programmers will only see that errors appear, which can have various causes. Even after the original error is corrected, they must change other calculations and documentation and retest each step.

Studies have shown that software specialists spend 40 – 50% of their time on avoidable rework rather than value-added work, which works that gets done right the first time. Once a piece of software hits the field, the cost of correcting a bug can be 100 times higher than it would have been during the development stage.

If mistakes abound, rework can start to flood a project, like a boat in a storm. What’s worse, attempts to correct one mistake often introduce new ones. It’s like you’re rescuing that boat, but you’re also creating leaks. If too many errors occur, the cost and time required to complete the system become so great that moving on is pointless.

In the simplest terms, an IT project generally fails when rework exceeds the value-added work budget. Is there are a solution? Although it is impossible to ensure that the project is 100% perfect, there are working techniques with which any errors that may arise can be minimized to a minimum. For a project to be successful, it needs to have at least the following elements:

A good estimation of the times: It is crucial to plan how the project will be carried out. It is catastrophic when goals are set that are impossible to meet in the indicated times. Reasonable quality control: Are you adding new features? Are you updating a site? Or are you directly doing it from 0? If so, you will need to thoroughly test every new piece of code you add so that you are entirely sure that it is foolproof code and will not break if someone does not understand it. On-the-go testing: Keep in mind that there is no such thing as perfect software. You should find a starting point to go into production and start testing the new software ―the sooner, the better. As stated, finding problems at the beginning is easier to handle and less expensive than identifying them at the last minute. In addition, involving different people from the team in the testing process can allow you to have a greater scope of interaction and a more global vision. An adequate design: In some cases (more than it should), non-conformities occur because the plan does not meet the requirements you need or, on the contrary, it becomes too complicated for a person to be able to use it without need for complex instructions Try new technologies: It is indispensable to continuously be updated with all the technologies coming out every day to make our work much more manageable. But there are times when, by not finishing testing the different tools before using them in an actual project, we make mistakes because we do not quit using this new technology correctly. Messy planning: Last and perhaps most important, have good planning. It is necessary to have an organized and systematic way of dividing all the phases of the work of a project so that you can be prepared for any eventuality, and it is possible to deliver the work on time. We, as humans, cannot avoid that in all projects. There is one error in the code, but we can control how many and severe they are. Thus, we must keep in mind that avoiding mistakes is equal to or even more important than the amount of work that gets done or, in other words, quality is better than quantity.

Do you have an idea and want to make a prototype to see if it is functional or sustainable over time? Then, 23blocks is the best solution that you will find to carry out this development with less effort and investment.

Each of our blocks is a combination of Software, Infrastructure, and Services, which are available as API Microservices. According to industry standards, these are hosted in a highly available cloud, ready for production and use.

Making the decision to start a software project can be complicated and intimidating. So, contact us at info@23blocks.com to receive free assistance from our software experts and get started on your idea.

There is a better way to build apps and platforms —the #23blocksway.

These products differ from no-code development platforms because they allow for a greater level of functionality with custom code rather than a drag-and-drop interface. Low-code platforms may allow users to develop applications without ever touching source code. Still, the ability to modify said code if the need arises sets these products apart from their no-code siblings. They also provide less functionality than a whole integrated development environment because they do not provide tools to create complete applications from scratch.

One of the best advantages of low code is that it does not require much coding knowledge (in the end, we always need to do that 20% of the code, so we need to at least have an idea of ​​how to program). Thus, the amateur or senior programmer can use the low code, which would work just as well.

Project low code development growth According to a recent Forrester report, the low-code market is set to reach an annual growth rate of 40%, with spending forecasted to hit $21.2 billion by 2022. Thus, with the rise of low-code development, there will also be increasing demand for customizable integration, implementation, and consulting services.

Interestingly, Forrester notes that no code/low code has the potential to make software building as much as 10 times faster than traditional methods. Furthermore, they note that these platforms help advance digital business in three major ways: a) greatly decrease time needed to meet business requirements b)harness shadow IT, and c) play a key role in automating operational processes.”

Figure 1 – Forrester forecast On the other hand, Gartner forecasts that no-code and low-code application platforms (NCAP/LCAP) will account for 80% of all application development by 2024. Moreover, it implies that most apps created in 2024 will be developed using tools that provide business-friendly ways to program.

Figure 2- Critical reasons for adopting low code solutions. So why should low code be used? We must go through its most essential characteristics so that we can have a clear idea of ​​what we will have in case we choose this type of development for our project:

Speed: As might be expected, given that the most cumbersome and lengthy parts of the project are already done (or it requires minimal changes), the platforms can be ready in much less time Decrease in errors: The low code in its base can be trusted to be correct and without errors. That is, you start with a large amount of the project of which you should not worry about mistakes, which ensures that the final project has a higher quality Lower Costs: Because all times are much lower (development, implementation, testing), it is understood that costs also decrease considerably Ease to use: Because low code platforms are characterized by being relatively easy to handle, you can expect to quickly learn how to use it and get to exploit its full potential. Reuse: There are cases in which you must do a project with templates, layouts, plugins, widgets, or modules. So, you can reuse these tools any number of times, making adding features much more effortless. Flexibility: Finally, low code development is not limited to a single platform type. It can be used for desktop and mobile platforms. The whole point of the low code is to beat the competition in speed without sacrificing the quality of the projects. So you can decide to stay behind with archaic practices that take time and effort beyond what is necessary or upgrade and start having projects much faster, cleaner, and more effective.

Do you have an idea and want to make a prototype to see if it is functional or sustainable over time? Then, 23blocks is the best solution that you will find to carry out this development with less effort and investment.

Each of our blocks is a combination of Software, Infrastructure, and Services, which are available as API Microservices. According to industry standards, these are hosted in a highly available cloud, ready for production and use.

Making the decision to start a software project can be complicated and intimidating. So, contact us at info@23blocks.com to receive free assistance from our software experts and get started on your idea.

There is a better way to build apps and platforms —the #23blocksway.

Wright Brothers and the first plane flight

In 1903, Orville and Wilbur Wright made the first successful flight in the history of a heavier-than-air self-propelled airplane. Orville piloted the gasoline-powered propeller-powered biplane, which floated for 12 seconds and covered 120 feet on its maiden flight.

The key to success can be summed up in great creativity, the ability to think visually and turn abstract ideas into functional hardware. Both brothers possessed extraordinary technical knowledge and a sophisticated approach to solving mechanical design problems. In 1892 they opened a bicycle repair and sale workshop. Soon, they were building their own bikes. This experience, combined with the profits from their various businesses, allowed them to actively pursue their dream of making the world’s first airplane.

Figure 1 – Stationary letterhead for 1034 West Third Street Wright Cycle Company, letter from Wilbur to Father Milton, courtesy of the Library of Congress Archives.

And it is that a feat that materialized in 1903 began many years before with multiple designs, recalculations, investigations, and MVPs (minimum viable products). For all this, several prototypes and tiny models were made. These sought to test theories; therefore, they had to be built quickly and agilely to save resources and take advantage of the moment’s emotion.

To build and test the different gliders created before the remarkable success, they reused from bicycles, kites, and even fans. Finally, on December 17th, the first 12-second human flight was made, and that would undoubtedly mark the course of history.

Figure 2 – Wright Flyer – Airplane Blueprint. Drawing Plans for Wright Flyer, built by Orville and Wilbur Wright, is a drawing by StockPhotosArtCom, uploaded on October 20th, 2018.

What can we learn from the Wright brothers? First, they did not try to make an airplane from scratch. Instead, they envisioned the reuse of other objects that together formed a new and innovative functional machine. Today, planes are not made with bicycles. However, in the 1900s, a bike was an essential key to success, allowing innovators to focus on the important problem and solve it.

“If you are looking for perfect safety, you will do well to sit on a fence and watch the birds; but if you really wish to learn, you must mount a machine and become acquainted with its tricks by actual trial.”

Wilbur Wright

Do you have an idea and want to make a prototype to see if it is functional or sustainable over time? Then, 23blocks is the best solution that you will find to carry out this development with less effort and investment.

Each of our blocks is a combination of Software, Infrastructure, and Services, which are available as API Microservices. According to industry standards, these are hosted in a highly available cloud, ready for production and use.

Making the decision to start a software project can be complicated and intimidating. So, contact us at info@23blocks.com to receive free assistance from our software experts and get started on your idea.

There is a better way to build apps and platforms —the #23blocksway