Forem: David Brown

How to Make Complex Business Apps Feel Simple for Users

David Brown — Fri, 11 Jul 2025 01:30:00 +0000

We’ve all worked with business apps that feel like puzzles—too many steps, too many fields, and not nearly enough guidance. The worst part? A lot of these apps are technically sound. They just feel complex, and that’s enough to turn users off.

But here’s the challenge: most enterprise apps aren’t complicated by accident. They have to manage real-world workflows, strict business rules, and multiple systems behind the scenes. So how do you deliver that level of functionality without overwhelming users?

That’s something I’ve had to figure out firsthand. And today, I want to share what’s worked for me—using Bellini, Lonti’s low-code app builder—as my go-to tool for building apps that feel simple, even when they’re doing a lot behind the scenes.

Start With the User Flow, Not the Features

It’s tempting to start with the feature list or the database schema. But the most important question is: What is the user trying to do?

I always begin by mapping the journey. If I’m building a dashboard for a sales manager, I’m thinking in terms of questions they need answers to—not just tables or charts. If it’s a workflow for operations, I break it down into steps they naturally follow in their day-to-day.

When you design the app around those flows, instead of stacking features on a screen, the experience becomes easier to understand and navigate—no matter how much complexity is going on in the background.

Reveal Complexity Gradually

One of my favorite UX principles is progressive disclosure: show users only what they need right now, and let them explore deeper options only if (and when) they need them.

In Bellini, I can build dynamic components that change based on user selections, permissions, or data. If someone selects a vendor, only then do I show the contract fields. If they check a box for advanced settings, I can reveal more UI elements. The goal is to keep the interface focused and non-intimidating by default, while still offering full control to power users.

Structure the UI Like a Conversation

I like to think of a good UI as a two-way conversation. Instead of dumping every input field on screen, I group things logically. Cards, accordions, and step-based flows go a long way toward making the app feel intuitive—even if it’s interacting with multiple APIs behind the scenes.

And speaking of APIs…

Let the Backend Do the Heavy Lifting

I don’t believe in stuffing the frontend with business logic. That’s what APIs are for.

With Bellini, I bind components to APIs built in Martini, Lonti’s integration engine. Those APIs are often based on models from Negroni, which standardizes data across systems.

This lets me build a responsive UI that reacts to real-time data—without making the front end brittle or overloaded. Need to trigger a multi-step process? That happens in Martini. Need to clean or format data? That’s handled before the UI ever sees it.

Design for 90%—Support the 10%

There will always be weird use cases, special conditions, or edge-case workflows that only one team uses. You need to support them—but they shouldn’t dominate the UI.

I isolate those flows with modals, secondary tabs, or toggles. That way, the core experience stays clean, and advanced users still have what they need.

Microcopy Is Underrated

I can’t stress this enough: naming matters. Instead of “Submit Entity” or “Execute Action,” I’ll use labels like “Submit for Review” or “Send Invoice.” It might seem small, but it makes the interface more human—and it builds trust.

Even error messages matter. A vague “Validation error” is useless. “Please enter a valid invoice number” is something the user can act on.

Watch Real People Use It

This one’s simple: observe someone using your app.

I’ve done screen shares where I just watch a user navigate through the UI. No explanations. Just observation. Every time, I’ve found something I could improve in minutes—whether it was rearranging components or adjusting defaults.

With Bellini’s visual interface, making those adjustments is fast. I can rebuild a better version before the next meeting.

Final Thoughts: Complexity in the Backend, Simplicity in the Front

Building powerful business apps doesn’t mean overwhelming users. It means making complex systems feel simple.

By designing around flows, revealing complexity gradually, and leaning on clean APIs, I’ve been able to build apps that are robust under the hood—but intuitive and fast on the surface.

Original source: How to Make Complex Business Apps Feel Simple for Users

The False Economy of “Cheap” Low Code Platforms

David Brown — Mon, 07 Jul 2025 01:30:00 +0000

Low-code platforms are everywhere right now. Some promise you can build apps in a weekend. Others brag about doing it for less than the cost of a SaaS subscription.

But here’s the truth: most “cheap” low-code tools? They’re expensive in all the wrong ways.

I’ve seen too many teams fall into the trap—myself included. You build fast, get something working, show it off… and then slowly start realizing what you’re in for:

Integrations that can’t scale
Logic you have to rewrite constantly
A platform that locks you in tighter than an old-school CMS

Let’s break down where it all goes sideways—and how we built Lonti to avoid it completely.

🚧 Cheap Now, Expensive Later

A lot of platforms are built for demos. Not for real-world complexity. They help you build a quick UI or connect to a simple API, but the moment you need:

Conditional workflows
Integration with legacy systems
Custom business logic or data structures

...you’re hacking, duct-taping, or worse—starting over outside the platform.

That “$20/month” tool? Suddenly you’re paying double to maintain workarounds.

🔒 The Lock-In Trap

Most of the “easy” low-code platforms do one thing really well: keep you inside their ecosystem.

Try exporting workflows to Git.

Try editing in your IDE.

Try integrating with your CI/CD pipeline.

Yeah… good luck.

With platforms like these, you’re not just locked in—you’re held hostage.

🧰 What We Did Differently with Lonti

We built Lonti because we were tired of watching real developers hit real walls.

Instead of simplifying everything, we focused on giving you:

Visual tools where they help
Full-code access when you need it
API-first architecture so you can integrate anything
Git, versioning, reuse, and scale—baked in from day one

🔹 Martini handles API automation and integration

🔹 Bellini builds frontend apps with both drag-and-drop + JS/CSS when needed

🔹 Negroni gives you structured data modeling + auto-generated APIs

Low code, yes. But with no limits.

🧠 Real ROI = Real Freedom

The biggest hidden cost in “cheap” low-code isn’t money.

It’s flexibility.

Every shortcut that saves time today? It costs you twice as much when the business changes and you can’t adapt.

With Lonti, we’ve had teams go from “internal MVP” to full-on enterprise rollout—without rewriting the stack.

That’s the kind of ROI that actually matters.

TL;DR

Not all low-code is built to scale
Cheap tools often come with hidden costs: lock-in, rework, and dev time
Lonti is low code made for devs—API-first, extensible, and built for real apps
You don’t have to trade speed for power anymore

Original source: The False Economy of “Cheap” Low Code Platforms

Automation Without APIs Is Just Fancy Macros

David Brown — Mon, 30 Jun 2025 01:30:00 +0000

Let’s get real for a second.

If your “automation” tool is just clicking buttons, mimicking keystrokes, and scraping screens... it’s not really automation. It’s a dressed-up macro. And in 2025, that’s not going to cut it.

I’ve worked with enough systems to know: if your automation can’t talk to your backend services via APIs, it’s brittle. It’s temporary. And it’s going to break—probably at the worst possible time.

🤖 UI Automation ≠ Real Automation

I’ve seen too many workflows hinge on screen scraping and simulated clicks. These setups work... until the UI changes. Or the layout breaks. Or someone renames a field.

Then? Boom—production issues, debugging nightmares, and a dev team trying to fix something they didn’t build in the first place.

That’s why I tell teams: If your automation relies on pixels instead of APIs, you’re building a house of cards.

💡 The Fix? API-First Automation

Here’s the shift that changes everything: think API-first.

Want to automate order confirmations? Hit the billing system’s API.

Want to sync data between your CRM, ERP, and support stack? Connect to those APIs directly. No spreadsheets. No screen scraping. No nonsense.

That’s what real automation looks like: event-driven, data-integrated, API-connected, and observable.

🧰 What We Use: Martini (Low Code, Built for Devs)

At Lonti, we built Martini specifically to enable this kind of automation. It’s a low-code platform—but before you roll your eyes, hear me out.

This isn’t “no-code for marketers.” Martini gives devs:

Visual workflow editors (fast prototyping)
Custom scripting (Groovy, JS, Java) where needed
Native API orchestration across any service
Reusable integrations, triggers, and transformations
Debugging, monitoring, and versioning built in

You can automate across REST, GraphQL, SOAP (yes, really), file systems, webhooks, queues—you name it.

🔍 Why It Works (When Other Tools Don’t)

Other platforms hide the complexity until it’s too late. Martini lets you embrace it—and control it.

No more “sorry, that’s not supported.”

No more glue scripts just to work around your platform’s limitations.

No more pretending a UI click is the same as calling a real endpoint.

⚠️ PSA: Don’t Call It Automation If It Can’t Call an API

If your automation tool can’t consume or publish APIs, it’s not automation. It’s just window dressing.

You need automation that:

Talks to your systems
Logs reliably
Fails gracefully
Can scale with your architecture

If you’re a developer who’s tired of watching fragile tools pretend to solve hard problems, I feel you. That’s why I stopped relying on macros and started building automation the way it should’ve worked from the beginning.

Original source: Automation Without APIs Is Just Fancy Macros

Why API Integration Is Too Important to Leave to Non-Developers

David Brown — Wed, 25 Jun 2025 01:30:00 +0000

Let’s be honest—API integration is one of the most deceptively complex tasks in modern development.

From the outside? Looks simple. Plug one system into another, pass some data, hit an endpoint. Done, right?

In practice? Welcome to the wild world of mismatched schemas, brittle auth flows, unpredictable rate limits, and half-baked docs.

That’s why it absolutely blows my mind when I see low-code platforms treating integration like a drag-and-drop form builder. Yes, visual tools are great—but pretending that non-developers can handle enterprise-grade integration without a hitch? That’s how teams end up rewriting everything six months later.

👨‍💻 Integration Is a Developer’s Job

Here’s the truth: if your API integration handles anything important—like syncing customer data, processing invoices, updating CRMs—you need it to be done by someone who understands:

Data modeling
Request/response structure
Auth schemes (OAuth2, API keys, token refresh)
Retry logic
Payload transformation
Versioning and schema evolution
…and all the edge cases that never make it into the docs

That’s developer work. Period.

**🧰 So We Built Martini: Low Code with Developer Control**

I’ve been on both sides—writing integrations from scratch, and fighting with tools that try to “simplify” too much. That’s why my team at Lonti built Martini.

It’s a low-code platform, but not the kind that tries to take developers out of the equation.

Instead, Martini is API-first and developer-focused. You can:

Visually orchestrate APIs
Write custom logic (Java, Groovy, JavaScript)
Secure endpoints and apply governance
Transform and map data visually or in code
Build error handling into the workflow itself
Publish services and expose them as REST or GraphQL APIs
Monitor everything with logs and runtime insight

And when you pair it with Negroni (data modeling) and Bellini (frontend builder), you get an end-to-end platform that respects how real apps are built.

🚫 No More One-Click “Connectors” That Break

You know what I’m talking about—those tools that promise “Connect to Salesforce in one click!” but the moment your API needs a custom header or response mapping, it falls apart. Or worse, you can’t debug it.

With Martini, you control everything. From how the API is consumed, to how it behaves under the hood.

It’s fast—but never fragile.

💡 Devs Shouldn’t Have to Fight Their Tools

Integration should be something developers can build confidently, quickly, and correctly. Not something we dread because we’re stuck babysitting middleware, debugging black boxes, or writing the same boilerplate over and over.

That’s what Martini is built to solve.

You can move fast.

You can go deep.

You can build things that actually scale.

And you never have to hand off mission-critical logic to someone who doesn't know what a 429 response code means.

Original source: Why API Integration Is Too Important to Leave to Non-Developers

How to Use Demo APIs to Level Up Your API Testing Skills

David Brown — Mon, 23 Jun 2025 01:30:00 +0000

Let’s face it—most mock APIs are useless.

They either return hardcoded nonsense, require weird sandbox logins, or are so shallow they fall apart the second you try to simulate something realistic. If you've ever tried to build or test anything beyond a to-do list, you know what I’m talking about.

That’s why I’m shouting out apiexplorer.io — a free, always-on playground full of fully functional, realistic business APIs. And yeah, I helped build it.

These aren’t toy endpoints. We’re talking about structured, documented, enterprise-style APIs — like:

CRM
Billing
Inventory
Payments
Ecommerce
HR and Task Management

All of them behave like real systems. So you can test like it’s production—without the risk of actually being in production.

What Makes apiexplorer.io Useful?

Here’s what you get out of the box:

RESTful API endpoints (CRUD ready)
OpenAPI docs
Postman collections
A browser-based API explorer
A working UI for each API (yes, you can log in and see what the data looks like)
API key-based auth (no OAuth pain here)

Just sign up, grab your API key, and get to work.

Example:

GET https://demo-api.apiexplorer.io/api/lonti_demo_api_crm/1.0/contact?limit=10
Headers:
  Accept: application/json
  X-Authorization: Bearer YOUR_API_KEY

Simple. Clean. Fast.

Use Case 1: Level Up Your API Testing Skills

Want to learn API testing with Postman? Practicing with curl? Writing unit tests that simulate real error conditions?

apiexplorer.io gives you realistic behavior, not just happy path JSON dumps. Test:

Authentication headers
Invalid inputs
Rate limits
Filtering, searching, pagination
Nested relationships

Trust me: It’s way better than mocking up endpoints by hand or spinning up a dummy Express server for the 500th time.

Use Case 2: Prototyping Integrations with Lonti (Optional but Cool)

If you’re using Martini (Lonti’s low-code integration platform), these APIs slot right in. Just import the OpenAPI spec, create a workflow, and boom—you’re running real workflows with real APIs.

Same if you’re building frontends in Bellini—you can bind components directly to these demo APIs and see actual data flowing, live.

That’s next-level prototyping speed.

Use Case 3: Practice Error Handling Like It’s Production

Most API tutorials stop at 200 OK.

In the real world? You’re dealing with:

401 Unauthorized
422 Validation Errors
500 Server Errors
Unexpected payload shapes

Use apiexplorer.io to simulate all of that—intentionally send bad data and see how your app responds. Train your test suite to handle failure like a champ.

Getting Started

Go to apiexplorer.io
Create a free account
You’ll be redirected to the Lonti Console where your API key is waiting
Hit any endpoint with the following headers:

Accept: application/json  
X-Authorization: Bearer YOUR_API_KEY

Browse the API Explorer, or start testing in Postman, curl, HTTPie, or your own app

Why We Built It

We’re devs. We got tired of building apps with garbage APIs or waiting for staging environments to be “ready.”

So we built what we needed: realistic, instant, enterprise-grade demo APIs—with the same standards we’d expect from any real backend.

And yeah, it’s free. No catch.

TL;DR:

If you're building, testing, or learning APIs, stop using trash examples.

Go to apiexplorer.io. Get a free key. Test your skills like it’s real life.

Happy hacking! 🚀

Original source: How to Use Demo APIs to Level Up Your API Testing Skills

How to Build Clean, Scalable Dashboards in Bellini

David Brown — Wed, 18 Jun 2025 01:30:00 +0000

Let’s cut to the chase: most business dashboards suck.

They’re cluttered. Hard to scan. Painful to maintain. And they often do a worse job answering a question than a basic SQL query.

As devs, we’ve all either inherited or built a dashboard like that. It works… technically. But it’s dense, inconsistent, and nobody wants to use it.

I’ve been there. So I ditched the usual drag-and-drop UI kits and started building dashboards in Bellini—Lonti’s low-code frontend tool that’s actually designed for developers. Not just for shipping fast, but for building right.

Here’s how I approach dashboard dev now—and how Bellini helps me do it faster without sacrificing flexibility.

**1. Start With the Why, Not the *What***

Before I drag in a single chart, I map out:

→ Who’s using this?

→ What decisions do they need to make?

→ What’s the one thing they should see right away?

If I can’t answer that, I shouldn’t be building a dashboard yet.

Bellini lets me sketch out responsive layouts fast—rows, columns, cards—without fighting rigid templates. So even in the prototyping phase, I can keep structure and intent aligned.

2. APIs Come First, Not Last

Bellini is API-native. Not just “connects to an API”—I mean, built around APIs.

I bind components directly to live API endpoints (REST or GraphQL). Sometimes those are custom APIs I expose with Martini, or models I standardize with Negroni. Sometimes they’re third-party services pulled straight into Bellini’s secure runtime.

The key: I don’t write glue code. I don’t hand-roll fetch wrappers. I just plug in the data and move on.

3. Clarity Beats Density

Here’s the truth: your dashboard isn’t a data dump. It’s a decision-support tool.

I follow three rules:

Use white space generously.
Prioritize one KPI per block.
Avoid chart soup (if it doesn’t answer a question, don’t include it).

Bellini gives me full CSS control and lets me plug in external libraries when needed (D3, Chart.js, GSAP—you name it). I’ve animated charts, styled cards, and even embedded SVG workflows, all without breaking layout or data bindings.

4. Make It Clickable (Without Overengineering It)

Dashboards should be interactive, not overwhelming.

Bellini supports all the goodies: filters, modals, paginated tables, conditional views—and you can inject custom JS wherever you want. I’ve built dashboards where:

Users filter orders by region
Drill down into customer history
Trigger backend actions like invoice resends or status updates

The logic sits alongside the UI. No context switching. No backend guesswork.

5. Reuse, Refactor, and Scale

My favorite Bellini feature? Reusable components.

I treat dashboards like real software. If I build a killer leaderboard component or a multi-tab KPI view, I refactor it into a reusable block. Bellini supports versioning, Git integration, and workspace sharing—so I can collaborate with other devs and still keep my components clean.

Frontend should be sustainable, not just fast.

TL;DR — Bellini Actually Gets It

Most low-code tools fall apart when your UI needs real logic. Bellini doesn’t.

Original source: How to Build Clean, Scalable Dashboards in Bellini

5 Ways Low Code Platforms Can Improve Business Agility

David Brown — Mon, 16 Jun 2025 01:30:00 +0000

TL;DR: Low code isn’t just for dragging buttons and making dashboards. If you care about moving fast and building things that last, developer-grade low code is probably your new best friend.

Let’s get something straight: “agility” is a buzzword until your stack actually helps you move.

We’ve all been there—an idea hits the roadmap, the team gets excited, and then… it stalls. Why? Because your systems aren’t flexible enough. Your integrations are brittle. Your backlog is backed up. And the thought of making real changes sends everyone into scope-paralysis.

I’ve been there. It sucks.

That’s why I’m a fan of low code—but not the kind that turns everything into a black box. I’m talking about platforms built for developers. Ones that speed you up, give you control, and don’t fall over when real-world complexity shows up.

We’ve been building with Lonti for a while now—specifically using Martini (integration & automation), Negroni (data modeling & APIs), and Bellini (frontend). And honestly? It’s changed how we deliver.

Here’s what that looks like in practice.

1. 🚀 Product Launches in Weeks, Not Quarters

Bellini gives you the kind of low-code frontend dev experience where you can drag in a UI, bind to a real API (REST or GraphQL), and ship something testable in a sprint.

Add in Negroni to define clean data models and Martini to orchestrate your API logic—and suddenly you’re deploying entire micro-apps without burning dev months.

Speed doesn’t have to mean throwaway code.

2. 🔁 Strategy Changes? React in Hours

One user had to reroute their B2B ordering logic halfway through a quarter. With Martini, it took a visual tweak to a workflow, a redeploy, and they were done. In. One. Day.

Compare that to untangling custom service layers just to rewrite some conditional logic…

This is why composability matters.

3. 🧠 Updating Processes Doesn’t Mean Breaking Everything

Martini is designed to let you build and update workflows without babysitting every change. Need to plug in a new approval path or trigger a webhook after a DB write? Visual config. Scriptable where it matters. And testable before it hits production.

No more praying your update doesn’t break a downstream system.

4. 🧱 Data Models You Don’t Rebuild Every Time

Negroni lets you model entities once and reuse them across apps, workflows, APIs—you name it. So you’re not mapping the same “customer” shape three different ways across three different tools.

That means fewer bugs. Less copy/paste. And a team that doesn’t hate working on “the integration layer.”

5. 🧑‍💻 Empower Devs (Don’t Replace Them)

A lot of low-code platforms treat developers like obstacles. Lonti’s tools are built with devs in mind. You can drop into Groovy or Java in Martini, bring your own JS libraries into Bellini, and use Git-based versioning when you need more control.

You’re not boxed in. You’re just working faster—with fewer keystrokes and more leverage.

Final Take

Low code doesn’t mean low effort—it means high leverage.

The Lonti stack helps you build real apps, fast, without surrendering flexibility. Whether you’re building internal tools, API integrations, or full production workflows, you’re working in one ecosystem that respects your brain and your time.

If your team’s been fighting backlog bloat, trying to deliver faster, or just tired of hacking everything together, give it a spin.

Original source: 5 Ways Low Code Platforms Can Improve Business Agility

Why Drag-and-Drop Alone Isn’t Enough for Serious Frontend Development

David Brown — Fri, 13 Jun 2025 01:30:00 +0000

Let’s get this out of the way: if you’re building serious apps, drag-and-drop alone isn’t enough.

Sure, it looks slick in a demo. You drop a button here, connect an API there, and suddenly you’ve “built an app in minutes.”

But if you’ve ever tried scaling that app past a single page, you already know what’s coming: the limits. The hard-coded logic. The UI quirks. The “not supported yet” error that sends you back to square one.

Drag-and-drop tools are fine—for forms, quick dashboards, maybe an MVP. But real-world business apps need more.

Real Frontend = Real Logic

Most low-code tools gloss over this part. They give you visual editors but skimp on what actually matters: logic, state, and integration.

I’m talking about:

Conditional rendering that doesn’t break on the second level of nesting
Custom validation that actually fits your use case
API binding that works with more than “dummy-data.json”
Reusable components with real props and scoped behavior

Without those, you’re just stacking UI elements with no soul.

Enter Bellini: Low Code for Devs Who Code

Bellini is the first low-code tool I’ve used that doesn’t feel like it’s fighting me. It’s built for developers—not just business users—and it shows.

You can:

Use the visual builder for fast layout and structure
Bind components directly to live APIs (REST, GraphQL, Martini, you name it)
Inject custom JavaScript functions and CSS
Drop in external libraries (yes, even your favorite JS charting lib)
Build your own components and reuse them across apps

In other words: you move faster, but still get full control.

API-First or Bust

Frontend apps live and die by their APIs. If your platform isn’t built API-first, you’re stuck building fragile UIs that break the moment a schema changes.

Bellini flips that.

It assumes APIs are the backbone of your app—so every component you use can bind to API responses, pass parameters, and even trigger downstream actions. That means you can build fast without hardwiring your logic to your UI.

Need to model your data? Use Negroni. Need to orchestrate APIs or automate stuff? Use Martini. It all fits.

Code Where You Need It. Visual Where You Want It.

Here’s the thing: I still want to code. I just don’t want to waste time coding what could be handled faster.

Bellini gets that balance.

I can:

Use visual tools for state and layout
Drop into JS whenever I need something custom
Extend components instead of rewriting them
Avoid rewriting boilerplate for forms, routing, and data fetching

And when I ship it? It works. It scales. It doesn’t scream “low code” at the user.

TL;DR: Visual Tools Are Great—Until They Get in the Way

If you’ve been burned by visual-only builders before, I get it. Same here. Most of them are great for fast starts but terrible for long-term development.

Bellini is different. It gives you drag-and-drop—but never locks you into it.

Need speed? You got it.
Need control? Write code.
Need reusability? Build components.
Need real data binding? APIs are first-class citizens.

Frontend dev doesn’t need to be slow. But it also doesn’t need to be boxed in.

Original source: Why Drag-and-Drop Alone Isn’t Enough for Serious Frontend Development

What’s the Fastest Way to Prototype an API Integration?

David Brown — Wed, 11 Jun 2025 01:30:00 +0000

You know the drill. Someone asks, “Can you whip up a quick API integration?”

You think: Sure, give me a few hours, Postman, some curl commands, a mock server, maybe a few tears...

But if you’re still prototyping integrations the slow, manual way, I’ve got good news—you don’t have to anymore.

Lately, I’ve been using a combo of apiexplorer.io and Martini to build fully working API integrations in minutes, not hours. And yes, it’s real code (where needed), real automation, and zero boilerplate.

Let me show you how.

Step 1: Start with apiexplorer.io

If you’ve ever had to mock up business APIs from scratch just to get a test flow working, you’ll love this.

apiexplorer.io gives you a full suite of production-style APIs—CRM, Billing, HR, Inventory, etc.—with:

RESTful interfaces
OpenAPI docs
Live testing via the API Explorer
Instant API key (no weird signup hoops)
Postman collections and even UI demos

Perfect for prototyping workflows without touching fragile live systems.

Step 2: Drop the OpenAPI into Martini

Martini is a low-code platform, but not the kind that makes devs cringe. You can:

Paste in OpenAPI specs or Postman collections
Auto-generate API connectors
Test requests right inside the IDE
Drop those services into actual workflows
Use visual builders or write code in Java/Groovy when needed

You’re not stuck in drag-and-drop land—you’re just skipping the boilerplate and jumping to the part where things work.

Step 3: Build the Flow, Wire It Up, Ship It

After importing the APIs, I build out a workflow visually in Martini:

Hit the CRM API
Pull customer data
Trigger a billing event
Log it, notify someone, or call another system

You can add logic, branches, retries, error handlers—the works. And once it’s running, publish it as an API endpoint or call it from another service. Done.

Bonus: Mock APIs Without the Headache

Need to simulate an external service? Martini lets you create mock APIs on the fly, so you’re not blocked by unfinished backends or flaky sandbox environments.

Switch the mock for the real thing later—no rewrites, no drama.

Final Thoughts

Fast API prototyping doesn’t mean cutting corners. It means skipping the setup grind and focusing on logic.

With apiexplorer.io + Martini, you get:

🔌 Realistic APIs you can test instantly
⚙️ A full workflow engine with visual + code modes
🔄 Reusable services and clean integrations
🧰 Tools made for developers, not just “citizen users”

No more digging through SDKs, building from scratch, or explaining to stakeholders why your “quick demo” needs two days of prep.

TL;DR

Want to build API clients without the mess?
Use apiexplorer.io + Martini
Build the workflow, test it live, and deploy—all in under an hour.

Try it. Break less. Ship more. 🧪⚡

Got questions or want to share what you’re building? Hit me up in the Lonti Community or drop a comment below. 👇

Original source: What’s the Fastest Way to Prototype an API Integration?

Building API Clients Faster with apiexplorer.io and Martini

David Brown — Mon, 09 Jun 2025 01:30:00 +0000

Let’s face it—getting started with API integrations is often the worst part of any project.

You want to build something fast, maybe mock a CRM flow or test a data sync idea. But instead, you’re stuck:

Scavenging for decent sandbox APIs
Fighting inconsistent docs
Writing glue code just to test a POST request
Wasting time debugging things that should just work

I got sick of that. So we built apiexplorer.io: a free playground of production-grade, fully documented, immediately-usable demo APIs. And when you pair it with Martini, our low-code API automation platform, you can go from “idea” to “working API client” in… well, lunch break territory.

Here’s how I use both in my workflow.

✅ Step 1: Realistic Demo APIs Without the Headaches

The problem with most mock APIs is that they’re either toy-level (/todos) or they gate everything behind auth walls and endless config.

apiexplorer.io fixes that. Once you sign up (free, no card), you get an API key and access to:

REST APIs for CRM, Billing, Orders, HCM, Inventory, and more
Live API Explorer with cURL + fetch snippets
Postman collections + OpenAPI schemas
A frontend app for previewing the data

Want to mock a customer profile system? Build a sales dashboard? Prototype lead assignment automation? You’re covered. You don’t even need to use Lonti tools for this—it works great with Postman or your own stack.

⚙️ Step 2: Consume the API in Martini

I use Martini to build integrations, workflows, and services visually (but with full code access when I want it).

Once I’ve grabbed my API key, here’s what I do:

In Martini, open the HTTP Client
Paste an endpoint like this: GET https://demo-api.apiexplorer.io/api/lonti_demo_api_crm/1.0/contact?limit=20
Add headers:
- Accept: application/json
- X-Authorization: Bearer YOUR_API_KEY
Click “Test”

Boom—live data.

From here, I can transform the payload, map fields, or embed this call into a workflow, webhook, or even an exposed API.

🔁 Step 3: Reuse, Reuse, Reuse

What’s cool about Martini is that any HTTP request I build can be turned into a reusable service.

Let’s say I build a “Get Contacts” call. I can:

Reuse it across 5+ workflows
Call it from an API published in Martini
Trigger it via automation or webhook
Or even wire it into a Bellini UI if I’m building frontend stuff

No duplicated logic. No boilerplate. Just a clean pipeline of services I can plug anywhere.

🎯 Real Example: From Demo API to Live Integration

I recently built a quick proof-of-concept that:

Pulled new leads from the CRM API (via apiexplorer.io)
Enriched them with external data
Routed them to an internal support queue
Notified users via Slack and updated our internal DB

Time to build: ~1.5 hours

Time spent on mocking/debugging the API layer: 0

That’s the whole point. This stack gets out of your way so you can build what matters.

TL;DR: A Better Stack for Prototyping with APIs

Here’s why I think apiexplorer.io + Martini is worth a try:

You get realistic APIs with clean structure and live data
No setup, no fluff—just test and go
Martini lets you orchestrate APIs visually, with full-code flexibility if needed
You can reuse everything across services, workflows, and frontend apps

I’m not saying it’s magic. But it’s a lot closer than what most of us deal with on a daily basis.

Original source: Building API Clients Faster with apiexplorer.io and Martini

Why Enterprise Apps Deserve Better UX Than Most Consumer Apps

David Brown — Fri, 06 Jun 2025 01:30:00 +0000

Let’s be honest—most enterprise apps are UX nightmares.

You open one up and instantly feel the friction: inconsistent layouts, buried actions, zero feedback when something breaks. It's like someone reverse-engineered usability just to punish the user.

And yet, these are the apps that power payroll, logistics, compliance, operations—actual mission-critical stuff.

Here’s my hot take: Enterprise apps deserve better UX than most consumer apps.

Not “just as good.” Better. Because the stakes are higher, the users are more focused, and the business impact is massive.

Why This Matters (Yes, Even to Developers)

As devs, we spend a lot of time thinking about data, architecture, and logic. But none of that matters if users can’t figure out how to navigate the damn UI. I’ve built apps that worked flawlessly on the backend—but users hated using them.

And that’s on me. Because building enterprise software isn’t just about solving the problem technically—it’s about delivering something people can actually use without getting frustrated.

What’s Gone Wrong With Enterprise UX

Somewhere along the way, enterprise apps got a reputation for being... functional. Not delightful. Not efficient. Just barely usable.

Here’s why:

We assume enterprise users will tolerate more friction.
We think good UX is a luxury for consumer-facing products.
We use tools that don’t prioritize UX (and we’ve accepted it).

But users now expect better. They've used apps like Notion, Slack, Linear, and Stripe. They know what good feels like—and clunky internal tools are no longer getting a free pass.

How We’re Fixing It with Bellini

That’s exactly why we built Bellini at Lonti—a low-code, API-first frontend builder that doesn’t sacrifice control. You can move fast and still ship polished, responsive, accessible apps.

A few things devs love:

Full API binding (REST/GraphQL), no boilerplate fetch logic
Reusable components and dynamic layouts
Drop in your own JS for logic or transformations
Bring your own CSS or design systems
Debug visually, inspect programmatically

Whether you’re building an internal tool or a full-blown enterprise UI, Bellini makes it feel like you’re writing frontend code—but with way less repetition.

It’s low code for people who could code everything—but shouldn’t have to.

UX Is a Dev Concern

If you're building frontend apps and treating UX as "someone else's job," you're missing the point. Good UX is your job, too—because bad UX will kill your app’s adoption faster than any bug.

So next time you ship something internal, ask yourself: would you want to use this every day?

If the answer is “no,” it’s time to raise the bar.

Original source: Why Enterprise Apps Deserve Better UX Than Most Consumer Apps

Measuring Developer Productivity Gains with Low Code APIs

David Brown — Mon, 02 Jun 2025 01:30:00 +0000

Let’s be honest: “low code” usually gets a bad rap with devs—myself included.

Most of the time, it means sacrificing flexibility for speed, or getting stuck in a no-code UI that feels like training wheels you can’t take off. And don’t even get me started on the boilerplate you still end up writing just to get an API up and running.

But a few months back, I tried out Martini, Lonti’s low-code API platform. Not because I thought it would change everything—but because I was tired of spending 30+ hours building every new internal API the same way over and over.

What happened next? Kind of wild: I built the same API in under 5 hours. And it wasn’t a toy. It was production-ready, secure, versioned, and hooked into real data.

Here’s what changed.

1. The Old Way: Hours of Boilerplate and Setup

Schema design → 1–2 days
Auth and security config → another half-day
API endpoint scaffolding → hours
Testing + docs → more hours
Deployment and monitoring? That’s a whole extra step

It works. It’s clean. But it’s slooooow.

2. The Martini Way: Visual Where It Helps, Code Where You Need It

With Martini, I:

Imported my data or modeled it visually (hello, Negroni for API-first data models 🙌)
Dragged in the backend logic I already had as reusable services
Bound them to endpoints instantly (REST or GraphQL? You choose)
Set up security with built-in modules (OAuth2, tokens, the works)
Published and tested from the same workspace

That’s it. No YAML wrangling. No Postman-fueled madness. Just clean APIs with actual reuse.

3. Reuse > Speed

You know what’s better than saving time building one API? Reusing it 10 times across apps.

Martini isn’t just about building fast—it’s about building once and reusing everywhere. Services, workflows, endpoints—they’re all versioned, callable, and composable. That’s where the real ROI kicks in.

4. Real Dev Tools Included

What really sold me was that I could still use code where it made sense.

Need to add logic? Inject Groovy or Java.

Want to extend something with a library? Go for it.

Need to version an API for a breaking change? It’s already baked in.

Low code doesn’t mean giving up control. At least not here.

TL;DR: Stop Copy-Pasting the Same API Logic

We’ve all got that one internal API we’ve rebuilt five different times in slightly different ways. Stop it. 😅

With a tool like Martini, you get back your dev time, keep your flexibility, and don’t sacrifice maintainability just for speed. Honestly, that’s the dream.

Original source: Measuring Developer Productivity Gains with Low Code APIs