DEV Community: Harsh Raval

I Compared 5 LLM Gateway Tools for Real-World Production Use

Harsh Raval — Wed, 23 Sep 2026 18:37:50 +0000

When an LLM application starts handling real users, calling a model API is usually easy. The problems show up around it. One provider hits a rate limit, another slows down, an endpoint goes down, retries drive up costs, or the application needs to switch models without rewriting half the codebase.

This is where an LLM gateway becomes useful. It sits between your application and model providers, giving you a central place to manage routing, reliability, observability, and access. I compared five widely used options, LiteLLM, Kong AI Gateway, Portkey, Bifrost, and Apache APISIX, to see how their approaches differ when production concerns such as traffic management, latency, provider failures, and operational control start to matter.

What Is an LLM Gateway?

An LLM gateway is a software layer that sits between an application and one or more large language model providers.

Think of it as a traffic controller for AI requests.

Without a gateway, an application may need separate integrations for providers such as OpenAI, Anthropic, Google, Azure, Amazon Bedrock, or self-hosted models. Each provider can have different APIs, authentication methods, rate limits, error responses, model names, and usage policies.

That complexity can quickly spread across an application.

An LLM gateway provides a central layer where much of that provider-specific logic can live.

A typical request looks like this:

Application → LLM Gateway → Model Provider → LLM Gateway → Application

Depending on the platform, the gateway can handle:

Model and provider routing
Load balancing
Rate limiting
Retries
Provider fallbacks
Authentication
Logging
Token tracking
Cost monitoring
Request monitoring
Access control
Caching
Usage policies

The exact feature set varies between gateways.

The important distinction is that an LLM gateway is not an AI model. It does not replace GPT, Claude, Gemini, or another model. Instead, it manages the infrastructure surrounding those models.

For a simple application using one provider, a gateway may not be necessary. For an application using several providers or handling substantial traffic, the centralized control can become much more valuable.

Why Do You Need an LLM Gateway in Production?

A direct model API integration can work perfectly well during development.

Things change when traffic becomes unpredictable.

Imagine an application receiving thousands of requests during a busy period. The primary model provider begins returning 429 rate-limit responses. Without a gateway, the application must decide whether to retry, wait, switch providers, or return an error.

With an LLM gateway, you can handle those policies in a centralized layer.
The same idea applies to model changes.

If provider-specific logic is scattered across several applications and services, switching providers can require significant development work. A gateway can provide a consistent interface while managing routing rules and provider configurations separately.

Visibility is another consideration.

When requests pass through a centralized gateway, engineering teams can gain a clearer view of latency, failures, token usage, provider behavior, and traffic patterns.

That information becomes particularly useful once an LLM application moves beyond experimentation.

A gateway can also help separate application logic from infrastructure decisions. Developers can focus on the application while platform teams manage routing, limits, authentication, and provider policies.

That does not mean every production application needs a gateway. If the application is small, uses one model provider, and has limited traffic, adding another infrastructure layer may create unnecessary complexity.

The value increases when provider diversity, traffic volume, reliability requirements, or governance become difficult to manage directly in the application.

How I Compared the LLM Gateways

I would not compare these tools purely on advertised requests per second.

A gateway can perform extremely well in a controlled benchmark and behave differently under a real application workload.

Production traffic introduces variables that simple benchmarks often miss. Requests can have different prompt sizes, responses can be streamed, traffic can arrive in bursts, and upstream providers can behave differently under load.

For this comparison, I focused on five areas.

Provider abstraction

How easily can an application work with different model providers?

A useful gateway should reduce the amount of provider-specific code developers need to maintain.

Traffic management

Can requests be routed, load-balanced, rate-limited, or directed according to defined rules?

This matters when applications use multiple deployments or providers.

Reliability

What happens when a provider times out, returns an error, or reaches a rate limit?

Retries and fallbacks can improve resilience, but they can also increase latency and cost.

Observability

Can engineers understand what is happening with requests?

Useful visibility includes latency, errors, tokens, costs, provider behavior, and request traces.

Operational control

How well does the gateway fit into the existing infrastructure?

A technically capable gateway may still be a poor fit if it introduces an operational model the engineering team does not want to maintain.

These criteria reveal differences that a single latency test cannot.

LLM Gateway Comparison at a Glance

LLM Gateway	Main Focus	Provider Abstraction	Routing & Load Balancing	Reliability & Fallbacks	Observability	Best For
LiteLLM	Multi-provider LLM management	Strong	Yes	Retries, fallbacks	Logging, monitoring, spend tracking	Teams using multiple LLM providers
Kong AI Gateway	API gateway + AI traffic management	Strong	Yes	Failover, retries	AI traffic, latency, tokens, costs	Organizations with existing API gateway infrastructure
Portkey	Routing, reliability, observability	Strong	Yes	Retries, fallbacks	Detailed request logging and tracing	Teams focused on reliable multi-provider routing
Bifrost	Performance and high-throughput gateway	Strong	Yes	Failover, load balancing	Logging and analytics	High-volume workloads where gateway overhead matters
Apache APISIX	Cloud-native API gateway + AI	Strong	Yes	Retries, fallback, health checks	AI-specific observability	Cloud-native teams already using API gateway infrastructure

Comparison of Leading Open-Source LLM Gateways

The five gateways take different approaches to the same underlying problem.

LiteLLM focuses heavily on multi-provider abstraction and centralized LLM management. Kong AI Gateway extends traditional API gateway capabilities into AI workloads. Portkey emphasizes routing, reliability, and observability. Bifrost takes a performance-focused approach to gateway infrastructure. Apache APISIX brings AI capabilities into a broader cloud-native API gateway ecosystem.

That makes the comparison more useful as an architectural evaluation than as a simple feature checklist.

LiteLLM

LiteLLM is built around a straightforward idea: applications should be able to interact with different LLM providers through a consistent interface.

Its Proxy Server provides a centralized gateway, while its Python SDK can also be used directly within applications. LiteLLM supports a large range of LLM providers and offers an OpenAI-compatible interface.

The platform also provides retries, fallbacks, spend tracking, authentication, rate limiting, logging, and monitoring.

Core strengths
The biggest strength is provider abstraction.

Instead of implementing separate application logic for every model provider, developers can use a common interface and move much of the provider-specific configuration into the gateway layer.

This becomes useful when a team is experimenting with several models or wants to avoid locking application code too tightly to one provider.

LiteLLM also provides routing capabilities for retries and fallbacks. When a deployment becomes unavailable or starts returning errors, routing rules can help determine what happens next.

Centralized controls are another useful part of the architecture.

Teams running multiple applications can manage authentication, budgets, rate limits, logging, and model access from a central layer rather than recreating those controls inside every service.

Best for
Best for teams that need broad model-provider support, a common API interface, and centralized management of LLM traffic.

The main production consideration is performance under the actual workload. If latency is critical, benchmark the full application path rather than relying on a generic gateway benchmark.

Kong AI Gateway

Kong approaches LLM traffic from the perspective of a broader API gateway.

That makes it relevant to organizations that already manage APIs through concepts such as authentication, routing, security, traffic control, and observability.

Kong AI Gateway supports multiple model providers and integrates AI traffic management into its wider gateway architecture.

Core strengths
Kong’s main strength is infrastructure-level traffic management.

Its AI Gateway supports routing, load balancing, streaming, authentication, access control, rate limiting, provider failover, and observability.

That combination becomes useful when LLM APIs are no longer an isolated application dependency and instead become part of a wider platform.

For example, an organization may already have API gateway policies for authentication, security, and traffic management. Bringing LLM requests into the same operational model can reduce the number of separate infrastructure systems engineers need to manage.

Kong also provides AI-specific visibility into requests, tokens, costs, and latency.

This lets you view AI traffic through the same infrastructure lens as other APIs.

Best for
Best for organizations that already use API gateway infrastructure and want AI traffic to follow established security, routing, governance, and observability patterns.

The trade-off is operational complexity. A broader infrastructure platform can require more gateway knowledge than a lightweight model proxy.

Portkey

Portkey focuses on the operational problems that become more visible when AI applications use multiple providers.

Its gateway provides a unified API and supports routing strategies such as load balancing, conditional routing, retries, and fallbacks.

Core strengths
Portkey’s approach centers on reliability and request-level visibility.

Suppose the primary provider returns an error. A configured fallback can route the request to another provider.

This can help applications recover from certain upstream failures without forcing every application service to implement its own provider-switching logic.

Portkey also provides visibility into requests and fallback attempts, which can make production troubleshooting easier.

Its load-balancing capabilities can distribute traffic between configured providers or deployments.

One important point to remember with fallbacks: they are not automatically free.

If the first request fails and another provider handles the request, the application can experience additional latency and model usage.

A fallback policy must balance availability, cost, and response time.

Portkey also provides logging, tracing, metadata, and metrics for understanding individual model requests.

Best for
Best for teams that prioritize routing, provider reliability, fallbacks, and detailed visibility into LLM requests.

Teams looking for a self-hosted, open-source gateway should also evaluate Portkey’s deployment and licensing model against their requirements.

Bifrost

Bifrost takes a performance-focused approach to LLM gateway infrastructure.

The project is written in Go and provides an OpenAI-compatible interface across multiple providers. Its documented integrations include OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure, Mistral, and Ollama.

Core strengths
Low gateway overhead and high-throughput infrastructure are central to Bifrost’s positioning.

Bifrost publishes performance benchmarks showing very low gateway overhead under specific test conditions. Those results can help you understand its performance goals, but you should not treat them as universal production guarantees.

Real-world latency depends on many factors, including hardware, concurrency, payload size, network conditions, streaming behavior, and the upstream model provider.

Bifrost also provides automatic failover, load balancing, semantic caching, request logging, analytics, and governance.

For teams processing large request volumes, minimizing infrastructure overhead can be an important part of the evaluation.

Best for
Best for teams that care strongly about gateway performance, high request volumes, and Go-based infrastructure.

Before deployment, test the exact providers and request patterns the application uses. This is especially important when the workload relies heavily on streaming or provider-specific API features.

Apache APISIX

Apache APISIX comes from the traditional cloud-native API gateway ecosystem.

That gives it a different position in the LLM gateway space. Instead of building an entirely separate infrastructure layer for AI, teams can extend an existing API gateway architecture to handle model traffic.

APISIX’s AI Gateway capabilities include model routing, load balancing, retries, fallback, token rate limiting, security, logging, and observability.

Core strengths
The biggest strength is flexibility within a broader API gateway ecosystem.

APISIX supports weighted model routing, health checks, token-based rate limiting, retries, fallback providers, and AI-specific observability.
This can help organizations already running APISIX for conventional APIs.

Instead of maintaining one gateway for normal application traffic and another specifically for AI requests, teams can potentially manage both through a common infrastructure layer.

The plugin architecture also gives infrastructure teams considerable control over how they handle traffic.

Best for
Best for cloud-native teams that want to manage traditional API traffic and LLM traffic through a common open-source gateway architecture.

The trade-off is complexity. The flexibility that makes APISIX useful can also mean more configuration and operational responsibility.

What Real Production Traffic Reveals

The biggest lesson from comparing LLM gateways is that production traffic changes the evaluation.

A development environment might send one request every few seconds.

Production can generate bursts of concurrent requests, long streaming responses, retries, provider rate limits, and sudden traffic-volume changes.

That is where gateway behavior becomes much more important.

For example, a provider might return a 429 during a traffic spike.

A retry could recover the request, but it can also increase latency and consume additional resources.

A fallback can improve availability, but sending the request to another provider may increase model usage and cost.

Load balancing introduces another consideration.

Distributing traffic between providers can reduce dependence on a single deployment, but providers can have different response times, prices, context limits, and model behavior.

That means routing is not simply an infrastructure decision. It can affect the application’s user experience and operating cost.

The same is true for caching.

Caching may reduce repeated model requests in workloads with predictable or repeated prompts, but you need to evaluate it carefully for applications where responses depend heavily on context or freshness.

Production testing should therefore reproduce the conditions that matter to the actual application rather than relying on one artificial traffic pattern.

What Should You Measure?

For a serious LLM gateway comparison, I would measure more than raw throughput.

p50 latency

This shows the typical request experience and provides a useful baseline for normal traffic.

p95 and p99 latency

Tail latency often matters more in production because it shows what slower requests look like during real workloads.

Error rate

Track errors under both normal and peak traffic. Also separate gateway errors from upstream provider errors where possible.

429 and timeout frequency

Rate limits and timeouts are common reasons for reliability problems in LLM applications.

Requests per second

Throughput helps establish how much traffic the gateway can handle under a particular configuration.

Gateway CPU and memory

A gateway should not consume disproportionate infrastructure resources simply to proxy model requests.

Token consumption

Token usage affects both performance and cost, particularly when retries and fallbacks are involved.

Provider fallback frequency

A high fallback rate can indicate provider reliability problems, routing issues, or an overly aggressive fallback policy.

Retry frequency

Measure retries because they can improve successful-request rates while also increasing latency and usage.

Cost per successful request

This is one of the most useful production metrics because a technically successful request is not necessarily an economically efficient one.

Streaming performance

Streaming applications should measure time to first token, sustained response behavior, interruptions, and completion time rather than treating the entire request as one latency number.

Most importantly, test failure scenarios.

A gateway that performs well while every provider is healthy tells you only part of the story.

A more revealing test is what happens when the primary provider slows down, returns errors, hits a rate limit, or becomes temporarily unavailable.

Which LLM Gateway Approach Fits Your Architecture?

The five gateways solve overlapping problems, but their priorities are different.

LiteLLM is centered on provider abstraction and centralized LLM management.
Kong AI Gateway connects LLM traffic with broader API gateway, security, and governance infrastructure.
Portkey emphasizes routing, reliability, fallbacks, and request-level observability.
Bifrost emphasizes performance and low gateway overhead.
Apache APISIX provides an extensible cloud-native gateway approach that can cover both conventional APIs and AI traffic.

The useful question is therefore not simply, “Which gateway has the most features?”

A better question is:

Which gateway matches the application's infrastructure, provider mix, reliability requirements, and operational model?

A small application with one model provider may not need all of these capabilities.

A multi-provider AI platform with significant traffic may need considerably more control.

Conclusion

An LLM gateway becomes increasingly useful when an application has multiple model providers, meaningful production traffic, or reliability and observability requirements that are becoming difficult to manage inside application code.

The five gateways take different approaches to the same underlying problem.

LiteLLM focuses on multi-provider abstraction and centralized LLM management. Kong AI Gateway brings AI traffic into a broader API gateway model. Portkey emphasizes routing, reliability, fallbacks, and request visibility. Bifrost focuses strongly on gateway performance and throughput. Apache APISIX combines AI gateway capabilities with a broader cloud-native API infrastructure.

There is no useful shortcut around production testing.

Use representative traffic. Measure p95 and p99 latency. Trigger provider failures. Test rate limits. Monitor retries and fallbacks. Track token consumption. Measure gateway resource usage. Then calculate what each reliability mechanism actually costs.

That gives you a much clearer picture than a feature list or a single benchmark.

An LLM gateway should ultimately make model infrastructure easier to control, observe, and change without pushing that complexity into every application service.

Frequently Asked Questions (FAQs)

1. What is an LLM gateway?

An LLM gateway is a software layer between an application and one or more large language model providers. It can manage model routing, authentication, rate limiting, retries, fallbacks, logging, monitoring, token usage, and other operational tasks.

2. Why use an LLM gateway in production?

An LLM gateway can centralize provider integrations and traffic-management logic. It can make it easier to switch providers, handle certain upstream failures, control usage, monitor requests, and manage multiple models without duplicating infrastructure logic across applications.

3. What is the difference between an LLM gateway and an API gateway?

A traditional API gateway manages general application API traffic. An LLM gateway adds capabilities designed around model traffic, such as provider routing, token-based limits, model fallbacks, token tracking, and LLM-specific observability. Some platforms, including Kong and Apache APISIX, extend traditional API gateway architectures with AI-specific capabilities.

4. Which LLM gateways support multiple AI providers?

LiteLLM, Kong AI Gateway, Portkey, Bifrost, and Apache APISIX can all manage traffic involving multiple LLM providers, although provider coverage, integrations, deployment models, and capabilities differ. Teams should verify support for the exact models and APIs their application requires before deployment.

5. How do you test an LLM gateway for production?

Test the gateway with traffic that resembles the real application, including normal requests, peak concurrency, streaming responses, rate limits, timeouts, and provider failures. Measure p50, p95, and p99 latency; error rates; throughput; resource usage; retries; fallbacks; token consumption; and cost per successful request.

I Found 20 Best Design Tools That Actually 10x My Productivity.

Harsh Raval — Wed, 23 Sep 2026 18:14:43 +0000

Designing faster does not always mean working faster. I have had plenty of days where I opened a design tool expecting to finish a simple screen and ended up spending hours fixing spacing, rebuilding components, searching for assets, creating wireframes, or switching between different apps to get one idea ready.

That made me rethink what a productive design workflow actually looks like. Instead of looking for one tool that supposedly does everything, I started looking for tools that remove specific bottlenecks.

The result is this list of design tools covering UI/UX design, AI-powered generation, wireframing, graphic design, web deployment, and AI image creation.

The Design Tools That Actually Make My Workflow Faster

I grouped these tools by the type of design work they handle best. Some are built for detailed interface design, some help generate ideas with AI, and others are better for graphics, websites, or early-stage brainstorming.

The important thing is not to use all of them. The goal is to find the tools that remove the most repetitive work from your own process.

UI and UX Design

1. Figma

Figma is one of the first tools I reach for when I need to move from an idea to a working interface without slowing down. I can design screens, build reusable components, create prototypes, and get feedback without constantly switching between different tools. That made it much easier to keep my design process moving when projects involved frequent changes.

Key features:

Auto Layout for flexible interface layouts
Components and variants
Interactive prototyping
Shared design libraries
Real-time collaboration
Comments and feedback
Developer handoff and inspection

Where it works best: Figma works particularly well for SaaS products, mobile apps, websites, design systems, and collaborative product teams.

Best for: Product UI design, collaborative teams, design systems, prototyping, and developer handoff.

Why it improves productivity: Reusable components and Auto Layout reduce repetitive adjustments when screens or content change.

2. Sketch

Sketch feels especially useful when the main goal is focused UI design rather than managing a huge range of creative tasks. Its reusable components and organized design system features reduce repetitive work when building interface screens. I found it useful for keeping product designs consistent while making changes quickly.

Key features:

Symbols and reusable components
Shared libraries
Vector editing
Interactive prototyping
Design documentation
Developer handoff
Component-based workflows

Where it works best: Sketch works well for product teams creating structured UI systems and designers who prefer a focused interface design environment.

Best for: Mac-based UI design, product interfaces, reusable components, and structured design systems.

Why it improves productivity: Reusable components make it easier to maintain consistency across large interface projects.

3. Adobe XD

Adobe XD brings wireframing, interface design, and prototyping into one workflow, saving time in the early stages of a product project. I can move from a rough screen idea to an interactive prototype without rebuilding everything in another application. For designers already familiar with Adobe’s ecosystem, that familiar workflow can make the design process feel more straightforward.

Key features:

UI and UX design
Wireframing
Interactive prototypes
Components
Design systems
Animation and transitions
Sharing and feedback

Where it works best: Adobe XD fits interface concepts, user flows, prototypes, and workflows connected to the Adobe ecosystem.

Best for: UI/UX concepts, wireframes, interactive prototypes, and designers already familiar with Adobe tools.

Why it improves productivity: Designers can move from wireframes to interactive prototypes without needing a separate application for every stage.

4. Framer

Framer stands out when I want a website to feel more polished and interactive without spending too much time moving between design and publishing tools. I can work on layouts, responsive sections, animations, and interactions while seeing how the final website is coming together. That combination is especially useful when visual quality and speed both matter.

Key features:

Responsive layouts
Interactive prototypes
Animations and transitions
Reusable components
Visual website editing
Web publishing
Responsive breakpoints

Where it works best: Framer works particularly well for landing pages, marketing websites, portfolios, interactive websites, and visually rich web experiences.

Best for: Interactive websites, high-fidelity prototypes, landing pages, responsive web design, and motion-focused experiences.

Why it improves productivity: Moving from visual design to a live website reduces some of the traditional design-to-development handoff.

AI-First UI & Generation Tools

AI design tools serve a different purpose. Instead of beginning with a blank canvas, they can help create an initial direction from a prompt, description, or rough idea.

5. Figma Make

Figma Make is useful when I have an interface idea but do not want to spend too much time starting from a completely blank canvas. Its AI-assisted approach can help turn an initial idea into something I can explore and refine inside the Figma workflow. For me, the biggest productivity benefit is getting to the experimentation stage faster.

Key features:

Prompt-based creation
AI-assisted interface generation
Interactive prototypes
Rapid iteration
Figma ecosystem integration
Faster experimentation

Where it works best: Figma Make is useful when a designer or product team wants to explore an idea quickly before spending time refining every visual detail.

Best for: AI-assisted UI exploration, rapid prototyping, product concepts, and teams already working in Figma.

Why it improves productivity: It can reduce the time it takes to create the first version of an interface from scratch.

6. Google Stitch

Google Stitch aims to reduce the time between a product idea and an initial interface concept. Instead of manually creating every screen from scratch, I can use natural-language input to quickly explore different UI directions. It is especially useful when I want several early concepts before deciding which direction deserves more detailed design work.

Key features:

Natural-language UI generation
AI-assisted interface concepts
Rapid screen creation
Quick design exploration
Prompt-based iteration
Early product visualization

Where it works best: Stitch is particularly useful for early product exploration, concept development, and creating visual starting points for team discussions.

Best for: Rapid UI concepts, early product ideation, prompt-based interface exploration, and quick design experiments.

Why it improves productivity: It helps reduce the blank-canvas stage of interface design.

7. v0 by Vercel

v0 by Vercel is particularly interesting when design and development need to move closer together. It can turn prompts into web interface concepts and code, which makes it easier to experiment with layouts without manually building every first version. I found that useful for quickly testing dashboard, SaaS, and web application ideas before spending more time refining them.

Key features:

Prompt-based UI generation
AI-generated web interfaces
Code generation
Component-based development
Rapid iteration
Design-to-code workflow

Where it works best: v0 works well for web applications, dashboards, SaaS products, prototypes, and developer-led interface experimentation.

Best for: AI-generated web UI, developer prototypes, dashboards, SaaS interfaces, and design-to-code workflows.

Why it improves productivity: It lets teams move from an interface idea to working code without treating design and development as completely separate stages.

8. Flowstep

Flowstep speeds up early product design, especially when I am still figuring out what an interface should look like. AI-assisted design exploration helps reduce the blank-page problem and gives me different directions to consider. Instead of spending too much time on the first version, I can focus faster on what actually works.

Key features:

AI-assisted product design
UI concept generation
Rapid design exploration
Faster iteration
Product design workflows
Reduced blank-canvas work

Where it works best: Flowstep is useful during early product development when teams need to explore multiple interface directions before committing to detailed design.

Best for: AI-assisted product design, early-stage UI exploration, rapid concept development, and testing different product directions.

Why it improves productivity: It speeds up early-stage exploration and reduces repetitive setup work.

9. Uizard

Uizard is helpful when I need to turn a rough product idea into something visual without building every screen manually. Its AI-assisted features let me create wireframes and mockups quickly, which is useful during brainstorming and early MVP planning. I especially like the way it makes interface ideas easier to communicate before a full design system exists.

Key features:

AI-assisted UI generation
Wireframing
Mockup creation
Templates
Rapid prototyping
Product visualization

Where it works best: Uizard works well for early product concepts, MVP planning, brainstorming, wireframes, and situations where non-designers need to communicate an interface idea.

Best for: Beginners, product ideation, wireframes, MVP concepts, mockups, and rapid UI visualization.

Why it improves productivity: It makes it faster to turn an abstract product idea into something visual that others can review.

Wireframing and Whiteboarding

Before detailed UI design starts, I often need a place to map ideas, user flows, or rough layouts. That is where whiteboarding and wireframing tools become useful.

10. Miro

Miro is less about creating polished interfaces and more about organizing the thinking that happens before design begins. I can use one workspace for brainstorming, user journeys, flowcharts, research notes, and team discussions instead of spreading that work across several places. That can save a surprising amount of time when a project starts with lots of ideas that need organizing.

Key features:

Infinite whiteboard
Sticky notes
Flowcharts
User journey mapping
Mind maps
Templates
Real-time collaboration

Where it works best: Miro works particularly well for workshops, brainstorming, user journeys, product planning, research synthesis, and remote team collaboration.

Best for: Team brainstorming, UX workshops, user journey mapping, product planning, and collaborative whiteboarding.

Why it improves productivity: It gives teams one shared visual space for messy early-stage thinking before ideas need to become polished designs.

11. Balsamiq

Balsamiq is one of those tools that becomes more useful when I deliberately want to keep a design rough. Its low-fidelity approach lets me focus on structure, navigation, and content instead of getting distracted by colors and visual details. That makes it easier to test an idea quickly and make major changes before investing time in polished UI design.

Key features:

Low-fidelity wireframes
Drag-and-drop interface elements
Rapid screen creation
Reusable UI controls
Simple annotations
Fast iteration

Where it works best: Balsamiq is particularly useful during early UX planning when the team needs to focus on page structure, navigation, and content hierarchy.

Best for: Low-fidelity wireframes, UX planning, information architecture, early product concepts, and quick layout testing.

Why it improves productivity: Low-fidelity designs are quick to create and easy to change before detailed visual design begins.

Graphic Design and Editing

Not every design task is a product interface. Marketing graphics, illustrations, documents, social media assets, and image editing require a different set of tools.

12. Adobe Photoshop

Photoshop remains useful when a design project requires detailed control over images, not just basic editing. I can work with layers, masks, retouching, compositing, and newer generative features in the same environment. For image-heavy design work, that level of control can significantly reduce the time spent switching between editing tools.

Key features:

Photo editing
Image compositing
Layer-based editing
Masking
Retouching
Typography
Generative AI features

Where it works best: Photoshop works well for detailed image editing, marketing graphics, product imagery, photo manipulation, and visual assets requiring pixel-level control.

Best for: Photo editing, image manipulation, marketing graphics, product images, and detailed visual retouching.

Why it improves productivity: Its extensive editing capabilities let me handle complex image adjustments without switching between multiple specialized tools.

13. Adobe Illustrator

I turn to Illustrator when the design needs to stay sharp and scalable at different sizes. You can create logos, icons, illustrations, and branding assets as vector artwork without worrying about losing quality as dimensions change. That makes it easier to create one asset that works across everything from a small icon to a large printed graphic.

Key features:

Vector illustration
Logo design
Icon creation
Typography
Shape-building tools
Color and gradient controls
Scalable artwork

Where it works best: Illustrator works especially well for branding, logos, illustrations, icons, packaging, and graphics that need to work across multiple sizes.

Best for: Logo design, branding, vector illustration, icons, packaging, and scalable graphics.

Why it improves productivity: Vector-based artwork can be resized without losing quality, reducing the need to recreate assets for different formats.

14. Adobe InDesign

InDesign becomes valuable when a project involves more than a single graphic and needs proper page structure. It gives me control over typography, grids, layouts, and multi-page documents, which makes long-form design work much easier to manage. For reports, brochures, magazines, catalogs, and ebooks, that organized workflow can save considerable editing time.

Key features:

Page layout
Multi-page documents
Typography controls
Grids and guides
Master pages
Print-ready documents
Digital publishing

Where it works best: InDesign is useful for brochures, magazines, reports, ebooks, presentations, catalogs, and other long-form visual documents.

Best for: Editorial design, brochures, magazines, reports, ebooks, catalogs, and long-form documents.

Why it improves productivity: Master pages, paragraph styles, grids, and reusable layouts make long documents easier to maintain consistently.

15. Canva

Canva is one of my quickest options when I need a professional-looking visual without spending much time building the design from scratch. Its templates and drag-and-drop workflow make everyday tasks such as social posts, presentations, thumbnails, and marketing graphics much faster. I find it particularly useful when speed matters more than having pixel-level control over every element.

Key features:

Templates
Drag-and-drop editing
Presentation design
Social media graphics
Brand kits
Image editing
AI-assisted design features

Where it works best: Canva works well for social media posts, presentations, marketing graphics, thumbnails, simple documents, and quick visual content.

Best for: Social media graphics, presentations, marketing content, thumbnails, simple designs, and quick visual assets.

Why it improves productivity: Templates remove much of the setup work when I need a professional-looking graphic quickly.

Web Design & Low-Code Deployment

16. Webflow

Webflow is useful when I want to take a website from visual design to a working published experience without relying heavily on traditional development workflows. I can build responsive layouts, manage content, add interactions, and handle many website details from the same environment. That makes it a practical productivity choice for designers working on marketing sites and content-driven websites.

Key features:

Visual web design
Responsive layouts
CMS
Animations
Interactions
Hosting
SEO controls

Where it works best: Webflow is particularly useful for marketing websites, business websites, landing pages, portfolios, and content-driven sites.

Best for: Professional websites, marketing sites, CMS-based websites, landing pages, and designers who want more control over web layouts.

Why it improves productivity: Designers can work directly with web layouts and publish changes without relying on a separate development workflow for every update.

17. FlutterFlow

FlutterFlow is useful when I want to move from a visual interface idea toward a functional application without building every part of the app manually from the beginning. Its visual development approach lets me work with screens, components, navigation, logic, and data while keeping the development process more accessible. I find it particularly useful when the goal is to turn a prototype into something closer to a working application.

Key features:

Visual app development
Drag-and-drop UI builder
Reusable components
App navigation and workflows
Database and API integrations
Responsive layouts
Code generation
Cross-platform app development

Where it works best: FlutterFlow works particularly well for mobile apps, web applications, MVPs, internal tools, dashboards, and projects that need a visual development workflow.

Best for: Low-code app development, MVPs, mobile applications, web apps, functional prototypes, and teams that want to move from design toward working products.

Why it improves productivity: Visual development, reusable components, integrations, and code generation can reduce repetitive development work required to turn an interface into a functional application.

AI Concept & Image Generation

Sometimes the problem is not designing the interface. It is creating the visual assets needed to communicate the idea.

18. Midjourney

Midjourney is useful when the biggest challenge is developing a strong visual direction rather than producing the final production asset immediately. I can explore different styles, compositions, moods, and creative concepts much faster than creating each idea manually. That makes it valuable during the early stages when I need visual inspiration before committing to a specific direction.

Key features:

Text-to-image generation
Visual concept exploration
Style experimentation
Image variations
Creative direction
Reference-based workflows

Where it works best: Midjourney is useful for concept art, moodboards, creative exploration, campaign ideas, and visual inspiration.

Best for: Creative concepts, moodboards, visual exploration, campaign concepts, and artistic image generation.

Why it improves productivity: It can generate multiple visual directions quickly instead of requiring every concept to be created manually.

19. Adobe Firefly

Adobe Firefly fits naturally into workflows where AI generation and traditional design editing need to work together. I can generate visual ideas, make edits, expand images, and experiment with variations without completely leaving the Adobe environment. For me, its productivity value comes from reducing the time spent on small creative changes that would otherwise require several manual steps.

Key features:

Text-to-image generation
Generative fill
Image editing
Generative expansion
Creative effects
Adobe ecosystem integration

Where it works best: Firefly is useful for designers who already work with Adobe applications and want AI-assisted generation or editing as part of their existing workflow.

Best for: AI-assisted image editing, Adobe workflows, creative variations, generative fill, and production graphics.

Why it improves productivity: Generative editing can reduce time spent on tasks such as extending images, removing elements, or creating visual variations.

20. Ideogram

Ideogram is particularly useful when the design depends heavily on readable text inside the generated image. I can explore poster layouts, typography-focused graphics, social visuals, and advertising concepts without manually creating every visual variation. It is a useful addition to the workflow when I want to test several text-heavy creative directions quickly.

Key features:

Text-to-image generation
Text rendering
Poster concepts
Typography-focused visuals
Creative variations
Image concept generation

Where it works best: Ideogram works well for posters, social graphics, advertising concepts, typography experiments, and visual designs where text needs to be part of the generated image.

Best for: Typography-focused graphics, posters, social media designs, advertising concepts, and text-heavy AI visuals.

Why it improves productivity: It can reduce the need to generate an image first and manually add all typography afterward.

20 Design Tools at a Glance

Tool	Category	Key Features	Where It Works Best	Best For
Figma	UI/UX	Auto Layout, components, prototypes, collaboration	Product design and design systems	Product UI and collaborative teams
Sketch	UI/UX	Symbols, components, libraries, prototyping	Structured product UI	Component-based UI design
Adobe XD	UI/UX	Wireframes, components, prototypes	UI/UX workflows	Interface concepts and prototypes
Framer	UI/Web	Responsive layouts, animation, publishing	Interactive websites	Design-led web experiences
Figma Make	AI UI	Prompt-based creation, AI generation	Rapid UI exploration	AI-assisted prototyping
Google Stitch	AI UI	Natural-language UI generation	Early product concepts	Rapid interface ideation
v0 by Vercel	AI UI	UI generation, code generation	Web apps and dashboards	Design-to-code workflows
Flowstep	AI UI	Product generation, exploration	Early product design	Rapid UI exploration
Uizard	AI UI	Wireframes, mockups, templates	MVP planning	Beginners and rapid ideation
Miro	Whiteboarding	Whiteboards, flows, mind maps	Workshops and planning	Team brainstorming
Balsamiq	Wireframing	Low-fi wireframes, UI controls	UX planning	Quick structural wireframes
Photoshop	Graphic Design	Editing, compositing, retouching	Image production	Detailed image editing
Illustrator	Graphic Design	Vector design, logos, icons	Branding and illustration	Scalable graphics
InDesign	Publishing	Page layouts, typography, grids	Long-form documents	Editorial and print design
Canva	Graphic Design	Templates, drag-and-drop, brand kits	Marketing content	Fast visual content
Webflow	Web Design	Visual development, CMS, SEO	Professional websites	Low-code web development
FlutterFlow	Low-Code App Development	Visual app builder, components, integrations, code generation	Mobile and web apps	Functional MVPs and app development
Midjourney	AI Image	Text-to-image, visual exploration	Creative concepts	AI image generation
Adobe Firefly	AI Image	Generative fill, image generation	Adobe workflows	AI-assisted image editing
Ideogram	AI Image	Text rendering, image generation	Posters and graphics	Text-heavy AI visuals

What Actually Makes a Design Tool Improve Productivity?

After using different types of tools, I think productivity comes down to a few practical things.

1. It reduces repetitive work

Reusable components, templates, styles, and automated layouts are often more valuable than a huge feature list.

2. It helps me get started faster

AI generation is particularly useful here. A rough starting point can be easier to improve than a completely blank canvas.

3. It makes changes easier

A good tool should make iteration simple. If changing one element requires manually fixing ten other things, the workflow quickly slows down.

4. It fits the next step

A design tool becomes more useful when it connects naturally to what happens afterward, whether that means prototyping, development, publishing, or content creation.

5. It matches the type of design work

There is no reason to use a complex UI design platform to make a simple social post, just as there is little reason to use a social design tool for a large product design system.

How I Would Choose Between These Tools

I would start with the task rather than the tool.

For product UI and UX, I would look at Figma, Sketch, and Adobe XD.
For interactive websites, Framer and Webflow make more sense.
For AI-generated interfaces, Figma Make, Google Stitch, v0, Flowstep, and Uizard are worth exploring.
For wireframes and early brainstorming, Miro and Balsamiq work well at different levels of detail.
For graphic design, Photoshop, Illustrator, InDesign, and Canva cover very different needs.
For AI-generated visual concepts, Midjourney, Firefly, and Ideogram each approach image creation differently.
For low-code app development, FlutterFlow helps when the goal is to move beyond a static design to a functional mobile or web application.

The goal is not to collect design tools. It is to build a workflow where each tool handles the part of the process it does best.

Conclusion

The design tools above cover almost every stage of a modern design workflow, including:

Rough brainstorming and wireframing
UI design
AI generation
Graphic editing
Website publishing
Visual concept creation

What made the biggest difference for me was not simply adding more software to the workflow. It was matching each tool to the task that was slowing me down.

Figma can simplify collaborative product design, while AI-first tools can speed up early exploration. Miro and Balsamiq can help organize ideas before detailed design, and Adobe tools provide deeper creative control. Webflow, Framer, or FlutterFlow can shorten the path from design to a live or functional product.

The productivity gain comes from choosing the right tool for the right bottleneck rather than trying to make one platform do everything.

Frequently Asked Questions

1. What are the best design tools for UI and UX design?

Figma, Sketch, Adobe XD, and Framer are UI and UX design tools that support interface design, prototyping, components, responsive layouts, and user-flow visualization. The most suitable option depends on the project’s workflow and requirements.

2. Which AI tools can generate UI designs?

Figma Make, Google Stitch, v0 by Vercel, Flowstep, and Uizard provide AI-assisted approaches to UI or product design. They can help generate initial concepts, interfaces, wireframes, or code from prompts and other inputs.

3. Which design tool is best for wireframing?

Balsamiq is focused on low-fidelity wireframing, while Miro is better suited to broader collaborative brainstorming, user flows, workshops, and visual planning. Uizard can also help generate early interface concepts using AI-assisted workflows.

4. What design tools are useful for graphic design?

Photoshop, Illustrator, InDesign, and Canva cover different graphic design needs. Photoshop suits image editing, Illustrator suits vector graphics and illustration, InDesign suits page layout and publishing, and Canva suits quick, template-based visual content.

5. How can design tools improve productivity?

Design tools can improve productivity by reducing repetitive work through components and templates, speeding up ideation with AI, simplifying collaboration, making iteration easier, and connecting design more closely with development or publishing. The biggest benefit comes from matching each tool to the workflow's specific bottleneck.

🐛 The Bug That Only Happened on Fridays 📅😱

Harsh Raval — Sun, 13 Sep 2026 16:23:02 +0000

🐛 The Bug

Every Friday afternoon, our checkout service started throwing intermittent 500s. Not all requests, maybe 1 in 50. Not every Friday either. Just most Fridays, starting sometime after 2 pm, and always gone by Monday morning. 😩

The error was unhelpful in the way only database errors can be:

error: sorry, too many clients already

Connection pool exhaustion. Except our pool was configured for 20 connections; on a normal Friday afternoon, we needed maybe 6, and nothing in our metrics showed a traffic spike. Whatever was eating connections wasn't customers. 🤔

🔍 Theory 1: A Slow Query Was Holding Connections Open

This was the obvious first guess. Somewhere, a query was taking forever, holding a connection the whole time, and eventually 20 of them piled up.

We checked pg_stat_activity during the next incident. Nothing. No long-running queries, no locks, no blocked transactions. Every connection was idle, not idle in transaction, not active. Twenty perfectly idle connections, and Postgres refusing to hand out a twenty-first.

Theory rejected ❌. If they were idle, the pool should've been reusing them.

🕵️ Theory 2: A Connection Leak in Our Own Code

Next suspect: somewhere in the app, we opened a connection and forgot to release it back to the pool. A classic leak. We'd shipped a new report-generation endpoint a few weeks earlier that ran a handful of raw queries outside our usual ORM wrapper, a very plausible place to forget a .release().

We audited it line by line. Every query went through a try/finally that released the client. We added logging around every pool.connect() and client.release() call, shipped it to staging, and hammered the reports endpoint with a script for an hour. Connections opened and closed exactly as expected. No leak.

Theory rejected ❌. At this point I was fairly sure we were cursed. 👻

📅 Theory 3: Some External Job Was Hammering the DB

We widened the search. Cron jobs? A scheduled Friday report someone set up two years ago and forgot about? We grepped every repo for cron, schedule, and setInterval, and found a weekly analytics export that ran Friday at 1 pm. Surely that was it.

Except the export used its own dedicated database user, and when we checked pg_stat_activity again, all 20 idle connections belonged to our checkout service's user, not the analytics job.

Theory rejected ❌. Again.

✅ The Actual Fix

The detail we'd been staring past the whole time: the connections were idle, but Postgres still wouldn't reuse them. That's not a leak. That's a pool that thinks its connections are busy when the database knows they're not.

We were running two instances of the checkout service behind a load balancer, each with its own connection pool capped at 20. Fine, that's 40 max connections total, well under Postgres's limit of 100. But we'd set up a third, older instance months back for a canary deployment experiment, and never fully decommissioned it. It wasn't receiving live traffic, so it never showed up in our request metrics or error dashboards. 👀

It was still running, though, and it still opened its full pool of 20 database connections on startup. Here's the actual killer: it had a bug in its health-check pinger that opened a new raw connection every few seconds instead of reusing one from the pool, and only cleaned them up when the process restarted. That process restarted every Friday because an auto-scaling policy recycled idle instances weekly. The leak reset itself every Monday, which is exactly why we could never catch it after the weekend, and why it always came back by Friday afternoon. 🎯

The "fix" that took two weeks of theorizing took five minutes to apply. We decommissioned the zombie instance. Connection counts dropped from a Friday peak of 94 to a steady 12, and the 500s never came back. 🎉

💡 What Actually Helped

pg_stat_activity grouped by application_name and usename, not just count. We assumed all 20 idle connections were "ours" because they were idle, not because we checked who owned them against every service that could plausibly connect, including services we'd forgotten existed.
Asking "what else is running" instead of "what's wrong with this code." Every theory we tried assumed the bug lived in the request path we were staring at. It didn't. It lived in infrastructure we hadn't thought about in months.
The weekly pattern was the actual clue, not a red herring. We treated "happens on Fridays" as an annoying detail of an otherwise generic bug. It was the whole story, screaming "something on a weekly cycle" the entire time, and we didn't listen until theory 3 forced us to go looking for exactly that.

The bug wasn't in the code we wrote that week. It was in a service we'd stopped thinking about entirely, which, in hindsight, is usually where the real ones hide. 🕯️

10 AI Website Builders I Tested So You Can Skip the Trial and Error

Harsh Raval — Wed, 09 Sep 2026 18:47:46 +0000

Choosing an AI website builder sounds simple until you actually try one: some create a beautiful first draft but give you little control afterward. In contrast, others can build surprisingly advanced applications but feel excessive for a basic business website. So which AI website builder is actually worth using? After comparing 10 popular options across AI generation, editing control, publishing, pricing, and the amount of manual work required after the first draft, I found that Wix is the best overall choice for most users; Hostinger offers strong value for beginners; and Squarespace stands out for design. At the same time, Lovable and v0 are better when your “website” is really a functional web application.

Quick Answer: Which AI Website Builder Should You Choose?

If you don’t want to read the entire comparison, start here:

Best overall: Wix
Best value for beginners: Hostinger Website Builder
Best for design: Squarespace
Best AI-first builder: Lovable
Best for developers: v0 by Vercel
Best for existing development teams: Builder.io
Best for WordPress: 10Web AI Builder
Best for speed: Durable
Best for entrepreneurs: GoDaddy Airo
Best for service businesses: B12

The important thing is that these platforms aren’t interchangeable. A freelancer building a five-page portfolio has very different needs from a startup building a functional web application. That’s why I wouldn’t choose based on the AI demo alone.

How I Tested These AI Website Builders

I looked at each platform from a practical website-building perspective rather than simply comparing feature checklists.

The main things I considered were:

AI generation: How effectively does the tool turn a basic description into a usable starting point for a website?
Editing control: Can you easily change the result without having to fight the builder?
Functionality: Can it handle forms, ecommerce, integrations, or application-level features when needed?
Pricing: What does the entry-level plan actually cost, and are there any promotional or credit-based pricing options?
Post-generation work: How much cleanup is needed before the website is genuinely ready to publish?
Best-fit scenario: Who gets the most value from the platform and who probably shouldn’t use it?

That last point matters. The best AI website builder isn’t necessarily the one with the longest feature list. It’s the one that creates the least friction for the type of website you’re trying to launch.

Best Overall AI Website Builders

1. Wix

Best for: Most businesses, freelancers, creators and beginners who want AI assistance without losing visual control.

Pricing: Wix offers a free starting option, while paid plans vary by market and plan. Paid plans add features such as a custom domain, increased storage and business functionality.

Wix is the easiest recommendation when you don’t have a highly specialized requirement. Its AI website builder can create an initial website from a description, after which you can continue editing the design and content visually. That combination is important because AI-generated websites rarely get every detail right on the first attempt.

The real advantage is what happens after generation. You aren’t forced to accept the AI’s decisions. You can continue adjusting pages, sections, layouts, content and business functionality.

Why I’d choose it: It provides one of the better balances between AI automation and traditional website editing.

Who should use it: Small businesses, freelancers, consultants, creators and anyone building a conventional business website.

Who shouldn’t use it: Developers who need complete control over the underlying application architecture.

Bottom line: If someone asks me, “What AI website builder should I try first?” Wix would be my starting point.

2. Hostinger Website Builder

Best for: Beginners who want an affordable all-in-one website setup.

Pricing: Hostinger’s current promotional pricing starts at $2.99/month for its Premium Website Builder plan. Its Unlimited plan starts at $3.99/month on the current 48-month promotional term, with a listed renewal price of $16.99/month.

Hostinger is interesting because the AI builder is bundled into a broader hosting experience. You don’t have to separately figure out where to host the website before you start building.

Describe the business, choose the general direction, and let the AI create the first version. You can then modify the content, layout, and other elements.

The low introductory price makes it attractive for people creating their first website, but don’t make the mistake of comparing the $2.99 promotional rate directly with a month-to-month competitor. The billing term and renewal price matter.

Why I’d choose it: Strong value when you need hosting and an AI website builder in the same package.

Who should use it: Startups, small businesses, bloggers, and beginners working with a limited budget.

Who shouldn’t use it: Teams that need highly specialized development workflows or advanced application architecture.

Bottom line: If cost is one of your biggest concerns, Hostinger deserves to be near the top of your shortlist.

3. Squarespace

Best for: Design-focused websites, portfolios and brands where presentation matters.

Pricing: Squarespace plans currently start at $16/month, and new websites can begin with a 14-day free trial. Pricing and available features can vary by billing cycle and region.

Squarespace takes a more design-led approach to AI website creation. Its Blueprint AI Builder helps generate a site structure and design direction based on your business information. Instead of giving you a completely blank canvas, it uses Squarespace’s established design system to produce a more cohesive starting point.

That’s useful when you care about how the website looks as much as how quickly it gets published.

Why I’d choose it: Strong visual consistency without requiring you to design everything from scratch.

Who should use it: Designers, photographers, consultants, creators, portfolios, and visually driven brands.

Who shouldn’t use it: Developers looking for extensive code-level control.

Bottom line: If your first question is “Will this website look polished?” rather than “Can I customize every technical detail?”, Squarespace is worth considering.

Best AI-First & Developer-Grade Builders

4. Lovable

Best for: Building functional websites and web applications from natural-language instructions.

Pricing: Lovable has a free starting plan. Its paid plans use a credit-based model, with the Pro plan currently listed at $25/month.

Lovable is where the definition of an “AI website builder” starts to change.

Instead of focusing primarily on pages, layouts, and visual editing, Lovable can help create functional applications with frontend interfaces, backend functionality, authentication, databases, and integrations.

That makes it much more interesting for founders and product teams than someone who wants a company homepage.

For example, if you’re building a customer portal, internal tool, or early-stage SaaS product, Lovable is closer to what you actually need than a conventional drag-and-drop website builder.

Why I’d choose it: It can take an idea beyond a collection of static pages.

Who should use it: Founders, startups, product teams, and technical users validating application ideas.

Who shouldn’t use it: Someone who only needs a simple five-page business website.

Bottom line: Don’t choose Lovable because it’s “more advanced.” Choose it when your project actually requires application-level functionality.

5. v0 by Vercel

Best for: Developers and teams building modern web applications.

Pricing:

Free: $0/month
Premium: $20/month
Plus: $30/user/month
Business: $100/user/month

v0 sits even closer to the development side of the spectrum.

Rather than treating AI as a replacement for the entire development process, it helps generate interfaces and application experiences that can fit into a modern development workflow.

That distinction matters.

If you’re a developer who wants to describe a UI and rapidly generate working code, v0 makes more sense than a traditional website builder. If you’re a nontechnical user trying to launch a local-business website, the opposite is probably true.

Why I’d choose it: It bridges natural-language generation and a real developer workflow.

Who should use it: Developers, technical founders, and product teams.

Who shouldn’t use it: Beginners who don’t want to deal with development concepts.

Bottom line: v0 is less “build me a website” and more “help me build this web experience.”

6. Builder.io

Best for: Teams with an existing codebase, design system or development workflow.

Pricing: Builder.io offers a free plan, while paid options vary by product and team requirements. Pro, Team and Enterprise options are available, with Enterprise pricing handled through sales.

Builder.io becomes more useful when you’re not starting from zero.

Its AI capabilities can work with existing development environments, design systems and code components. That makes it particularly relevant to organizations where designers, marketers and developers need to collaborate without creating disconnected versions of the same experience.

This is a fundamentally different use case from generating a standalone website.

Why I’d choose it: It can bring AI into an existing design-and-development system instead of forcing a team to start over.

Who should use it: Product teams, developers, enterprise teams, and organizations with established design systems.

Who shouldn’t use it: Individuals building a basic personal website.

Bottom line: Builder.io makes the most sense when you already have a technical foundation to build on.

Best for WordPress & Migrations

7. 10Web AI Builder

Best for: WordPress users creating new sites or rebuilding existing websites.

Pricing: The AI Starter plan currently starts at $10/month, with an annual option listed at $120 for 12 months under the current offer.

10Web is one of the more obvious choices if WordPress is already part of your workflow.

Instead of asking you to abandon WordPress for a proprietary website platform, it combines AI website creation with a WordPress-based environment.

That can be useful when migrating, rebuilding, or creating multiple WordPress websites and you want AI to accelerate the initial work.

Why I’d choose it: You can use AI assistance without moving away from WordPress.

Who should use it: WordPress users, agencies, and businesses already invested in the WordPress ecosystem.

Who shouldn’t use it: Someone who has no reason to use WordPress and wants the easiest possible website builder.

Bottom line: If WordPress is non-negotiable, 10Web should be on your shortlist.

Best for Small Businesses & Service Providers

8. Durable

Best for: Small businesses that want a website quickly.

Pricing: Durable offers a free starting option, while paid plans currently start at $22/month.

Durable’s biggest strength is simplicity.

You describe your business, and the platform creates a website around that information. For someone who doesn’t want to spend a weekend choosing templates, arranging sections, and writing every piece of website copy, that speed can be valuable.

The trade-off is customization. A simple business website doesn’t necessarily need hundreds of design controls, but a highly branded or technically unusual site may eventually need more flexibility.

Why I’d choose it: Speed and simplicity.

Who should use it: Local businesses, contractors, freelancers, and entrepreneurs who need a basic online presence.

Who shouldn’t use it: Businesses that need highly customized digital experiences.

Bottom line: Durable is about getting online quickly, not turning website creation into a design project.

9. GoDaddy Airo

Best for: Entrepreneurs and local businesses that want AI-assisted websites and business setup.

Pricing: GoDaddy Airo offers a free plan with 50 AI credits per month. Its Starter plan is currently listed at $9.99/month when billed annually.

Airo is interesting because its AI capabilities extend beyond simply generating website pages.

The platform is designed around helping entrepreneurs start and manage online business activities, and its AI Builder can also create more functional web experiences.

That makes it a useful option for someone starting with a business idea rather than a detailed technical specification.

Why I’d choose it: It connects website creation with the broader process of starting an online business.

Who should use it: Entrepreneurs, local businesses, and people starting from scratch.

Who shouldn’t use it: Development teams that already have their own technical stack.

Bottom line: Airo makes more sense when the website is part of a broader business setup.

10. B12

Best for: Professional service businesses that need their website to support customer acquisition.

Pricing:

Free: Available with a B12 subdomain
Website: $49/month
Website + Client Engagement: $78/month
New-user promotion: $1/month for the first three months

B12 takes a different approach from inexpensive AI website generators.

It focuses heavily on service businesses and combines website creation with tools for managing customer interactions, forms, payments, marketing, and other business processes.

That means the price shouldn’t be compared directly with a basic $3-per-month website builder.

You’re paying for a broader business-oriented platform.

Why I’d choose it: The website can become part of the business workflow rather than remain a standalone brochure.

Who should use it: Consultants, professional services, agencies, and other service-based businesses.

Who shouldn’t use it: Someone who only needs a basic portfolio or personal homepage.

Bottom line: B12 is more compelling when lead generation and client management matter as much as the website itself.

AI Website Builder Pricing: What You Should Actually Compare

The lowest advertised price isn’t necessarily the cheapest option.

Before choosing an AI website builder, look at these five things:

Introductory price: Is the advertised price temporary?
Renewal price: What will you pay after the promotional period?
Billing term: Does the low price require an annual or multi-year commitment?
AI credits: Does heavy AI usage cost extra?
Included features: Are hosting, domains, ecommerce, forms, and business tools included?

For example, Hostinger’s low introductory price looks very different once you consider its long-term billing requirement and renewal rate. B12 costs considerably more, but it also targets a different customer and offers broader client engagement capabilities.

In other words, don’t compare $3/month with $49/month until you know what you’re actually getting for that money.

Which AI Website Builder Is Best for You?

Here’s the simplest way I’d make the decision:

Choose Wix if: You want a flexible general-purpose website builder with AI assistance and visual control.
Choose Hostinger if: You want an affordable all-in-one website setup.
Choose Squarespace if: Design quality and visual consistency are your top priorities.
Choose Lovable if: You’re turning an idea into a functional web application.
Choose v0 if: You’re a developer who wants AI-assisted code and interface generation.
Choose Builder.io if: You already have a development system, design system, or codebase.
Choose 10Web if: You want to stay within WordPress.
Choose Durable if: You need a straightforward small-business website quickly.
Choose GoDaddy Airo if: You’re an entrepreneur looking for an AI-assisted business setup.
Choose B12 if: You’re a service business that needs integrated website and client engagement functionality.

What I Learned From Comparing These Tools

The biggest difference isn’t actually AI quality.

It’s how much control you need after AI finishes the first draft.

That’s the part many AI website builder comparisons miss.

Generating a website is now relatively easy. The harder question is what happens when you tell the builder:

“This headline is wrong.”
“I need another landing page.”
“Change this section without breaking the layout.”
“Add a booking workflow.”
“Connect this to my existing system.”
“I want to change the design without rebuilding everything.”
“I need this website to become an actual application.”

A simple AI website builder may handle the first request beautifully and struggle with the fifth. A developer-grade tool may handle the fifth but be unnecessarily complicated for the first.

That’s why I wouldn’t call one platform the universal winner.

The right level of AI matters more than the maximum amount of AI.

Conclusion

After comparing these 10 AI website builders, my overall pick for most people is Wix because it offers a practical middle ground between AI automation and hands-on editing. Hostinger Website Builder is especially appealing when keeping the initial cost low matters, while Squarespace is the better fit for design-focused websites.

Once you move beyond conventional websites, the shortlist changes. Lovable and v0 by Vercel make more sense for functional web applications and developer-led projects. Builder.io is better suited to teams with an existing technical system, while 10Web is the natural choice for WordPress users.

For entrepreneurs and service businesses, Durable, GoDaddy Airo, and B12 each take slightly different approaches to getting a business online.

The main lesson from testing these platforms is simple: don’t choose an AI website builder because it produces the fastest first draft. Choose the one that will still work for you after the first draft is finished. That’s where the real difference between these tools becomes clear.

Frequently Asked Questions (FAQs)

1. What is the best AI website builder in 2026?

Wix is the best overall AI website builder for most users because it combines AI website generation, visual editing, and business features. Hostinger is a strong lower-cost alternative, while Squarespace is better suited to design-focused websites.

2. What is the cheapest AI website builder?

Hostinger currently has one of the lowest advertised starting prices, with its Premium Website Builder starting at $2.99/month on the current promotional term. However, the billing period and renewal price should be considered before comparing it with other platforms.

3. Can AI really build a complete website?

Yes. AI website builders can generate website structures, pages, text, images, and basic functionality from natural-language instructions. AI-first platforms such as Lovable and v0 can go further by helping create functional web applications. However, human review is still needed for content accuracy, branding, SEO, accessibility, and final quality.

4. Which AI website builder is best for beginners?

Wix and Hostinger Website Builder are strong choices for beginners because they combine AI generation with visual editing and require little or no coding. Squarespace is another good option for users who prioritize design.

5. What is the best AI website builder for developers?

v0 by Vercel and Lovable are strong options for developers and technical teams. v0 is particularly useful for AI-assisted code and modern web development workflows, while Lovable is better suited to turning natural-language ideas into functional applications.

GiveTrack: A Personal Generosity Tracker Built for the DEV Weekend Challenge

Harsh Raval — Fri, 04 Sep 2026 11:04:54 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

GiveTrack is a personal generosity tracker that helps you log donations, discover causes, and actually see your impact over time instead of giving once and forgetting about it.

The idea came from a simple frustration: most people who give to charity have no easy way to look back and understand their own generosity, how much, how often, to what causes. GiveTrack turns that invisible habit into something visible and motivating.

It includes:

A dashboard with donation metrics and recent activity
Searchable causes you can browse and support
Create-cause and demo-donation modals to log giving
A filterable donation history

A "Generosity Chain" that visualizes your giving streak and impact over time
Random kindness prompts to nudge small acts of generosity

An AI Giving Assistant (powered by Google's Gemini API) that suggests giving ideas based on your activity
Fully responsive, mobile-friendly UI

It's a local first prototype. All data lives in the browser via localStorage, so you can try the whole experience instantly with zero sign-up.

Demo

🔗 Live app: https://give-track-generosity-app--harshravaldj.replit.app/

(Note: no real payments are processed. This is a demo experience with seeded/demo data you can reset anytime.)

Code

harshravaldj / give-track-generosity-app

GiveTrack – a personal donation tracker built for the DEV Weekend Challenge: Generosity Edition. Log and visualize your charitable giving to stay accountable and see your impact over time.

How I Built It

Built entirely on Replit, using the Replit Agent to scaffold the app, iterate quickly, and manage version control (GitHub) directly from the workspace. It let me go from idea to a fully deployed, publicly testable app in a single weekend without leaving the browser.

GiveTrack is built as a pnpm monorepo:

Frontend: React + TypeScript, with a custom visual system for the dashboard, modals, and Generosity Chain
Backend: Express 5 API server
Database: PostgreSQL with Drizzle ORM (schema-first, type-safe queries)
Validation: Zod end-to-end
API contracts: OpenAPI spec with Orval-generated hooks, so frontend and backend stay in sync automatically
AI: Google's Gemini API, accessed via a Google AI Studio API key, called server-side to keep the key secure. It powers the "AI Giving Assistant," which suggests giving ideas based on activity. It has a friendly deterministic fallback if the provider is ever unavailable, so the app never breaks.

One deliberate decision: donations and cause data are demo/local-first (localStorage) rather than wired to a real payment processor. For a weekend build, this let me focus on the experience of tracking and reflecting on generosity, rather than payment infrastructure, while keeping the door open to add real giving flows later.

Prize Categories

Submitting for Best Use of Google AI. The AI Giving Assistant calls Google's Gemini API (via a Google AI Studio key) server-side to generate personalized giving suggestions.

I Compared 5 Open-Source LLM Gateways for Enterprise AI

Harsh Raval — Thu, 03 Sep 2026 18:44:27 +0000

Your AI stack works fine with one model. The moment you add a second provider, a fallback, a rate limit, or a cost ceiling, everything breaks. Routing logic bleeds into application code, API keys get hardcoded, teams duplicate retry logic across services, and suddenly your “enterprise AI” is just a pile of half-working integrations held together by environment variables. That’s exactly the problem open-source LLM gateways solve, and in 2026, the options have matured enough to pick one seriously.

What an LLM Gateway Actually Does (and Why You Need One)

An LLM gateway sits between your application and every model provider OpenAI, Anthropic, Azure, Cohere, Mistral, local models, whatever. It normalizes the API surface, handles routing, enforces rate limits, logs requests, manages keys, and gives you failover without touching application code.

Without one, you’re solving the same problems in every service: retry logic, model fallback, token tracking, cost controls. With one, you solve it once at the infrastructure layer.

The four capabilities that matter at enterprise scale:

Unified API surface — one endpoint regardless of which model is behind it
Load balancing and fallback — route to backup providers when primary fails or rate-limits
Observability — token usage, latency, cost, and errors in one place
Access control — centralized API key management, team-level quotas, audit logs

Open-Source LLM Gateways Worth Evaluating in 2026

1. Helicone

Helicone is the one that shows up when teams need serious observability baked into the gateway layer, not wired in afterward through a separate logging pipeline. It’s built as a proxy you can drop in front of any OpenAI-compatible endpoint, and monitoring starts immediately, with no instrumentation changes in the application code.

What separates Helicone from most gateways is the depth of the request-level data it captures by default: token counts, cost per request, latency, user-level attribution, and custom properties you tag at call time. That makes it practical for teams that need to answer “which feature is driving our AI spend” rather than “how many tokens did we use this month.”

Key capabilities:

One-line proxy setup changes the base URL; observability starts immediately.
Request logging with cost tracking, latency, and custom metadata per request
User-level and session-level attribution out of the box
Prompt management and versioning with A/B testing support
Caching layer to reduce duplicate calls and control spend
Self-hostable or managed cloud deployment

Best for: Teams that prioritize observability and cost attribution above everything else. Particularly useful when multiple teams or product features share the same LLM budget, and you need to break down spend by owner.

Trade-offs: Helicone is observability-first, and fallback logic is less of a focus compared to LiteLLM or Kong. If your primary problem is multi-provider failover rather than usage visibility, you’ll likely combine Helicone with another routing layer or use a different tool.

2. LiteLLM

LiteLLM is the most widely adopted open-source LLM proxy in 2026, and for good reason: it supports more model providers than any other and has an enormous community contributing to it.

It exposes a single OpenAI-compatible endpoint to 100+ models. You point your app at LiteLLM, configure your providers in a YAML file, and the gateway handles translation, retries, and fallback.

Key capabilities:

Broadest provider support: OpenAI, Anthropic, Azure, Bedrock, Cohere, Mistral, Ollama, and dozens more
OpenAI-compatible API (minimal code changes to adopt)
Budget controls per key, per team, per model
Built-in spend tracking and cost dashboards
Proxy server with Redis-backed caching

Best for: Teams that need maximum provider coverage and a battle-tested community project. If you’re standardizing across a heterogeneous model portfolio, LiteLLM has the widest support.

Trade-offs: The breadth comes with configuration complexity. At large scale, self-hosting LiteLLM requires careful tuning; it can become a performance bottleneck if not provisioned correctly. Observability is functional but not as deep as Helicone’s native offering.

3. Kong AI Gateway

Kong built its reputation on API gateways for microservices, and Kong AI Gateway extends that into LLM traffic. If your organization already runs Kong for API management, this is a natural addition; it plugs into the same control plane, uses the same plugin architecture, and fits into existing GitOps workflows.

Key capabilities:

Semantic caching to reduce duplicate LLM calls (and cost)
AI prompt engineering plugins (injecting system prompts at the gateway level)
Rate limiting, authentication, and logging via existing Kong plugins
Multi-cloud support with declarative configuration
Enterprise tier available with dedicated support

Best for: Enterprises already on Kong for API management, or teams that need gateway-level prompt manipulation without application changes.

Trade-offs: If you’re not already in the Kong ecosystem, the setup overhead is real. It’s a heavier deployment compared to purpose-built LLM gateways. The AI-specific features are also more recent, so they’re not as mature as Kong’s core gateway capabilities.

4. Apache APISIX

APISIX is a high-performance API gateway that added LLM routing support in recent versions. It’s CNCF-hosted, runs on NGINX under the hood, and is built for teams that need raw throughput at scale.

The LLM plugin layer handles provider routing, load balancing, and basic observability. What APISIX brings is performance; it consistently outperforms other gateways in requests-per-second benchmarks at high concurrency, which matters when you’re processing thousands of simultaneous LLM calls.

Key capabilities:

High-throughput architecture (Lua-based plugins, NGINX core)
Dynamic routing without reloads
Plugin ecosystem covering auth, rate limiting, observability, and transforms.
Strong Kubernetes integration
Active Apache Software Foundation governance

Best for: Teams where raw gateway performance is the primary constraint, high-volume inference pipelines, real-time applications where latency margins are tight.

Trade-offs: LLM-specific features (semantic caching, cost tracking, model fallback chains) are less mature than those of purpose-built LLM gateways. You’ll likely need to build or integrate additional tooling for production-grade LLM observability.

5. Envoy AI Gateway

Envoy Proxy is the infrastructure backbone for many service meshes (Istio, for one), and Envoy AI Gateway extends it with LLM-specific routing capabilities. The value proposition is clear if you’re already running Envoy: you add AI routing to an existing, hardened proxy layer rather than operating a separate gateway.

Key capabilities:

Built on battle-tested Envoy infrastructure
Token-based rate limiting (not just request-based, critical for LLM cost control)
Header-based routing and model selection
Strong observability via existing Envoy metrics pipeline
Native integration with service mesh deployments

Best for: Teams running Istio or other Envoy-based service meshes who want to add LLM routing to existing infrastructure. Also strong for teams with strict compliance requirements that need request-level auditability.

Trade-offs: Envoy AI Gateway is earlier-stage than the others. Configuration is verbose (Envoy’s xDS API is powerful but not quick to get right). If you don’t already know Envoy, the learning curve is steep.

Side-by-Side Comparison

Feature	Helicone	LiteLLM	Kong AI Gateway	Apache APISIX	Envoy AI Gateway
Provider Support	OpenAI-compatible endpoints	100+ (broadest)	Major providers	Major providers	Major providers
API Compatibility	OpenAI-compatible	OpenAI-compatible	OpenAI-compatible	Plugin-based	xDS / HTTP
Fallback / Failover	Limited (observability focus)	✅	✅	✅	✅
Semantic Caching	✅	Partial	✅	Limited	❌
Native Observability	✅ Deep (core feature)	✅ Basic	✅ Via plugins	✅ Via plugins	✅ Via Envoy metrics
Token-Level Rate Limiting	✅	✅	✅	Request-level	✅
Cost Tracking	✅ Per request + per user	✅ Budget controls	Partial	Limited	❌ Native
Kubernetes Native	✅	✅	✅	✅	✅
Setup Complexity	Low	Low	Medium–High	Medium–High	High
Maturity	Mature	Mature	Mature (AI layer newer)	Mature (AI layer newer)	Early-stage
Best Fit	Observability + cost attribution	Max provider coverage	Kong-ecosystem teams	High-throughput pipelines	Envoy/service mesh teams

How to Pick One Without Overthinking It

The gateway decision usually comes down to three questions:

1. What’s already in your infrastructure?

If you run Kong, use Kong AI Gateway. If you run Envoy/Istio, evaluate Envoy AI Gateway. If you’re greenfield, pick based on capabilities.

2. How important is deep observability?

If you need cost attribution per team, per project, or per feature, and you don't want to wire up five separate tools, Helicone’s native approach wins. The proxy setup is a single base URL change; request-level tracing, cost tracking, and user attribution work immediately with no additional instrumentation.

3. How many providers do you need to support?

If your answer is “all of them” or close to it, LiteLLM has the broadest support and the most community-contributed integrations.

What “Enterprise Scale” Actually Breaks

A gateway that works in development often fails in production for one of three reasons:

Stateless routing at high concurrency: Most gateways handle this fine, but verify your chosen gateway can handle thousands of simultaneous streaming connections without memory bloat. Envoy and APISIX have the strongest track record here.
Fallback logic for partial provider failures: If a provider is degraded (slow responses rather than hard failures), naive retry logic can make things worse. Look for gateways that support circuit breakers and timeout-based fallback, not just error-code-based fallback.
Cost attribution at the team level: Token usage without team-level attribution means your finance team can’t audit spend, and engineering teams have no incentive to optimize. This is a gap across several gateways: Helicone and LiteLLM handle it natively, while APISIX requires external tooling.

Conclusion

Running enterprise AI at scale isn’t a model problem; it’s an infrastructure problem. The model is the easy part. Routing, fallback, cost controls, observability, and access management are where teams consistently underestimate complexity.

The right gateway is the one that fits your existing stack and solves your actual bottleneck, whether that’s provider breadth, raw throughput, observability depth, or the need to integrate with an existing Kong or Envoy deployment. None of these projects is a wrong choice; they have different priorities.

What matters is picking one and centralizing your LLM traffic through it before that routing logic spreads across every service in your stack and becomes impossible to audit or change.

I Let AI Design Tools Build My Portfolio Site — Clients Noticed

Harsh Raval — Wed, 02 Sep 2026 16:57:08 +0000

A portfolio website should make it easy for a potential client to answer three questions: What do you do, who do you work with, and can you actually deliver? The problem is that building a portfolio that communicates all three can take far longer than expected. I wanted to see if AI design tools could handle the first version without making the site look like another generic AI-generated template.

So I used the same core brief with Flowstep, Figma Make, Google Stitch, v0 by Vercel, and Banani, and then reviewed the outputs as I would for a real client project. The result was useful: AI handled the repetitive design work surprisingly well, but the parts that made the portfolio feel credible still needed human decisions.

The Prompt I Used

I didn't create a massive prompt for each tool. I wanted something realistic that I could actually reuse across different AI design tools.

The Prompt:

Create a modern, professional portfolio website for a digital designer and web developer who helps businesses build high-quality websites and digital experiences.

Include a strong hero section with a clear headline, short introduction, and CTA, followed by selected projects, services, about me, skills, work process, client testimonials, and a contact section.

Make the portfolio project-focused, with space to show screenshots, project goals, my role, services provided, and results. Highlight website design, UI/UX, responsive design, and real estate website development services.

Use a clean layout, strong typography, generous whitespace, subtle interactions, and a professional color palette. Keep the navigation simple and make the site fully responsive across desktop and mobile.

The overall design should feel polished, trustworthy, and human, not like a generic AI-generated template. Keep the copy concise and client-focused, explaining what I do, who I help, and why clients should work with me.

I used this as the starting point rather than changing the entire brief for each tool. That made the comparison much more useful because I could see how differently each platform interpreted essentially the same requirements.

What I Wanted From the AI Tools

I wasn't trying to prove that AI could completely replace a designer.

That wasn't the point.

I wanted to answer a much more practical question:

Can AI get me from a blank canvas to a portfolio worth showing clients without spending days on the initial design?

For me, the important requirements were simple:

Clear positioning
Strong project presentation
Professional visual hierarchy
Responsive layouts
Simple navigation
Useful service sections
Clear contact CTA
Enough flexibility to make manual changes

I also wanted to avoid the typical AI-generated website problems: oversized headlines, excessive gradients, meaningless animations, generic stock imagery, and copy that sounds like it was written for every business on the internet.

AI Design Tools I Used to Build My Portfolio Site

1. Flowstep

🔗 Live output: https://app.flowstep.ai/file?activeFileId=5ebe0443-1d8e-47ca-a30f-fe4fea6ce392

I started with Flowstep before touching Figma Make, mostly because I wanted to see how far one prompt could take me before I had to think about individual screens.

Instead of generating a single homepage and leaving me to figure out the rest, it laid out the whole flow at once: hero, work, services, about, and contact all appeared together as connected screens rather than a page I'd have to keep re-prompting for.

What changed how I worked was being able to nudge things by hand while still prompting. If a section's spacing felt off, I didn't have to describe it in words and wait; I could adjust it directly, then prompt for the next piece. That back-and-forth felt closer to actually designing than to filling out a form.

When I wanted a specific direction, I fed it a couple of reference screenshots and a short written style guide instead of describing the look in a paragraph. It picked that up more reliably than plain-text prompts did.

Getting it into Figma was the part I expected to be annoying, and it wasn't: no plugin, copy and paste straight from the tool into a Figma file to keep refining there.

What I kept

The multi-screen structure from a single brief
The overall hero-to-contact flow
Section spacing once I'd nudged it manually

What I changed

Hero copy, same as with every other tool
A couple of service-section labels
Minor project-card sizing after pasting into Figma

Since I was already thinking about implementation, I also exported the React, TypeScript, and Tailwind version of a few sections, and there's an MCP setup that pipes that code straight into Cursor or Claude Code if you want to skip the copy-paste step entirely.

That made Flowstep the tool I'd reach for first when I want a full flow to react to, not just one page.

2. Figma Make

🔗 Live output: puzzle-igloo-74654147.figma.site

Figma was the first place I wanted to test the prompt because I already think of portfolios primarily as interface and information architecture problems.

The first output gave me something much more valuable than a finished website:

a direction.

Instead of starting with an empty design file, I had a homepage structure to inspect and question.

The basic flow was:

Hero → Work → Services → About → Process → Testimonials → Contact

That structure made sense, but I didn't accept every decision it generated.

I immediately looked at the hierarchy.

Was the most important project getting enough attention?

Was the service offering clear?

Could someone understand my specialization without reading the entire page?

Were the CTAs competing with each other?

Those questions were more important than whether the interface looked impressive.

What I kept

Overall page structure
Project-card approach
Clear section hierarchy
Simple navigation
Responsive thinking

What I changed

Reworked the hero copy
Reduced unnecessary decorative elements
Adjusted spacing
Improved project descriptions
Made the CTA more specific
Removed generic visual treatments

This was the first point where I realized something important:

AI gave me a good starting point, but I still had to design the experience.

3. Google Stitch

🔗 Live output: stitch.withgoogle.com/projects/7200596362741624643

Google Stitch was useful for a different reason.

Instead of becoming attached to the first layout, I used it to explore another interpretation of the same portfolio brief.

That is where AI design tools become genuinely useful.

Normally, exploring three or four different directions means creating multiple versions manually. With AI, I could get alternative concepts much faster.

I paid particular attention to how it handled:

Hero layouts
Project grids
Typography
Section spacing
Service presentation
Mobile layouts
CTA placement

One version looked visually strong but pushed the portfolio projects too far down the page.

Another had a better hierarchy but felt too much like a template.

I wouldn't have wanted either version exactly as generated.

But together, they gave me enough ideas to make a better final direction.

That's the part of AI-assisted design that I find most useful:

You don't necessarily need AI to give you the final answer. You need it to give you more good options quickly.

4. v0 by Vercel

🔗 Live output: portfoliosite-portfolio.vercel.app

Vercel's v0 made more sense once I moved beyond visual exploration.

At this stage, I wanted to see how the portfolio sections could translate into functional web components.

For example, instead of simply designing a project card, I could generate a working project section with:

Project image
Category
Description
Technology tags
CTA
Responsive behavior

That's a different kind of productivity from that of a pure design tool.

I found this particularly useful for the repetitive parts of a website.

Navigation, cards, buttons, forms, grids, and responsive sections don't necessarily need to be built from scratch every time.

But I still reviewed the generated implementation.

I checked the structure, responsiveness, spacing, accessibility, and whether the components actually made sense for the portfolio.

The biggest mistake would be treating generated code as automatically production-ready.

Fast generation is useful. Blind acceptance isn't.

5. Banani

🔗 Live output: app.banani.co/preview/oo_s2sFFvkv9

Banani was another interesting part of the experiment because I wanted to see how another AI-powered design workflow would interpret the same portfolio requirements.

I kept the brief consistent rather than creating a special prompt designed to make Banani look good.

That gave me a more realistic comparison.

The generated concepts helped me evaluate different approaches to:

Portfolio layouts
Case-study presentation
Hero sections
Service blocks
Visual hierarchy
Responsive structure

The most useful part wasn't any single generated screen.

It was being able to compare ideas.

For example, one layout might have had a stronger hero while another handled project presentation better. Instead of choosing one output and accepting everything, I could take the strongest ideas from the different concepts and refine the structure myself.

That's closer to how I would actually use AI on a professional project.

The Biggest Changes I Made Manually

This is where the portfolio stopped looking like an AI experiment and started looking like my actual work.

1. I rewrote the hero section

AI-generated headlines often try to sound impressive.

I wanted mine to be immediately understandable.

The visitor shouldn't have to decode what I do.

A portfolio headline should quickly communicate the service and its audience.

2. I made the projects more specific

A screenshot alone doesn't explain why a project matters.

I added context around:

The problem → My role → What I built → The outcome

That makes a portfolio much more useful to someone considering hiring you.

3. I removed unnecessary design effects

AI tools like giving interfaces visual personality.

Sometimes that's useful.

Sometimes it means adding effects simply because they can.

I removed anything that didn't improve usability or communication.

4. I simplified the navigation

A portfolio doesn't need a complicated menu.

I wanted visitors to find the work and contact information quickly on the homepage.

5. I checked mobile layouts manually

This is one area where I don't trust the first generated result.

A desktop design can look excellent while the mobile version has awkward spacing, oversized text, or poorly cropped images.

I checked each major section separately.

What Clients Actually Noticed

The biggest change wasn't that someone recognized the website as AI-generated.

They didn't.

People noticed that the portfolio was easier to understand.

The projects were clearer.

The services were easier to find.

The website looked more consistent.

Most importantly, visitors could understand what type of work I actually do without having to dig through the entire site.

That's an important distinction.

Clients aren't hiring you because you used Figma Make, Stitch, v0, or Banani.

They care about whether your website gives them confidence that you understand their problem.

If someone is looking for real estate website development services, for example, they don't necessarily care which AI tool created the initial layout. They want to see whether you understand property listings, lead generation, responsive interfaces, conversion paths, and their business requirements.

The tool is behind the scenes.

The result is what gets noticed.

What I Would Use Each Tool For

After testing the four approaches, I wouldn't treat them as direct replacements for one another.

I'd use them differently.

Tool	Where I’d Use It
Flowstep	Full multi-screen flows, fast handoff into Figma and code
Figma Make	Interface exploration and refinement
Google Stitch	Quickly exploring different visual directions
v0 by Vercel	Functional UI and web components
Banani	Generating and comparing UI concepts

That workflow is more realistic than asking one tool to do everything.

My AI-Assisted Portfolio Workflow

If I were building another portfolio from scratch, I'd keep the process straightforward.

1. Define the audience

Know exactly who you want the portfolio to attract.

2. Write one useful brief

Describe your services, audience, sections, and visual direction.

3. Generate multiple concepts

Use AI to explore possibilities instead of immediately choosing the first result.

4. Select the strongest structure

Look at hierarchy and usability, not just visual appeal.

5. Build the interface

Use the tool that makes the most sense for the implementation stage.

6. Rewrite the important copy

Your positioning and project descriptions shouldn't sound generic.

7. Review everything manually

Check desktop, tablet, and mobile layouts.

8. Test the message

Show the site to someone unfamiliar with your work and ask:

“What do you think I do?”

If they can't answer quickly, the portfolio still needs work.

The Real Lesson From Building It With AI

AI didn't magically create a portfolio that clients noticed.

It helped me get to a strong starting point much faster.

That's the real advantage.

The tools handled a lot of the repetitive work involved in creating layouts, exploring variations, and producing interface components. That gave me more time to focus on the things that actually determine whether a portfolio works: positioning, project selection, content, hierarchy, and usability.

I also wouldn't recommend publishing the first design an AI tool generates.

The first output should be treated as a draft.

The second pass is where the real design work begins.

Conclusion

Using Flowstep, Figma Make, Google Stitch, v0 by Vercel, and Banani to build my portfolio showed me that AI design tools are most useful when they accelerate decisions rather than replace them. I could move from a blank canvas to multiple workable directions much faster.

Still, the final improvements came from reviewing the layouts, rewriting the copy, simplifying the interface, and making the project work easier to understand. That's ultimately what clients noticed: not that AI helped build the site, but that the finished portfolio clearly communicated what I do, what I've built, and how I can help them.

My AI Gateway Added 400ms to Every Request. Here's Where It Went

Harsh Raval — Wed, 02 Sep 2026 16:21:42 +0000

If your AI application suddenly becomes 300–500ms slower after adding an AI gateway, the first question should not be “Is the gateway slow?” It should be “Which part of the gateway is actually consuming the time?” An extra network hop can add latency, but a 400ms increase is usually a sign that something more than simple request forwarding is happening. In practice, the delay can come from connection setup, DNS or TLS negotiation, authentication lookups, synchronous logging, policy checks, retries, buffering, provider selection, or simply measuring time incorrectly. Modern AI gateways generally add milliseconds, not hundreds of milliseconds, when they are warm and properly configured, so a large increase warrants a request-level trace rather than guesswork.

The first thing I checked: direct API vs gateway

The most useful test is also the simplest.

I sent the same request to the model provider in two ways:

Directly from the application to the provider.
Through the AI gateway to the same provider.

Everything else stayed the same: model, prompt, API key, generation settings, region, and request payload.

The important number is:

Gateway overhead = gateway request latency − direct provider latency

That distinction matters because the total response time includes model inference. If the direct request takes 900ms and the gateway request takes 1.3 seconds, the gateway did not necessarily “make the model slower.” The gateway added roughly 400ms somewhere around the provider call.

This is also why average latency can be misleading. I prefer comparing p50, p95, and p99, because a gateway can look perfectly healthy at the median while connection setup, overloaded workers, or retries create painful tail latency.

Where the 400ms usually goes

When an AI gateway adds hundreds of milliseconds, I break the request into separate stages rather than treating the gateway as a single black box.

A typical request looks roughly like this:

Client → Gateway → Authentication → Policy → Routing → Provider → Streaming response → Gateway → Client

Each stage needs its own timestamp.

For example:

Stage	What to Measure
Client → Gateway	Network + TLS
Authentication	Token/key validation
Policy Checks	Rules, limits, classification
Routing	Model/provider selection
Gateway → Provider	Connection + network
Provider TTFT	Model processing
Streaming	First token and token delivery
Logging	Synchronous audit/telemetry work

If the gateway reports only “request completed in 1.3s,” you still don't know where the 400ms went.

That was the first lesson: measure the individual stages, not just the final response time.

1. Connection setup can quietly add latency

One of the easiest problems to miss is connection reuse.

If the gateway creates a new outbound connection for every AI request, the request can incur DNS lookup, TCP setup, and TLS negotiation costs repeatedly.

That is unnecessary overhead for a high-volume AI application.

The provider connection should normally be pooled and reused. The same principle applies to the connection between your application and the gateway.

I would check:

Are HTTP keep-alive connections enabled?
Is the HTTP client reusing connections?
Is connection pooling configured correctly?
Is DNS being resolved repeatedly?
Is TLS being negotiated for every request?
Are idle connections being closed too aggressively?
Is the gateway running close to the provider region?

This is especially important for short AI requests. If the model returns quickly, network setup becomes a much larger percentage of total latency.

For longer generations, provider inference usually dominates, but that does not make inefficient connection handling acceptable.

2. Authentication should not hit a database every time

Another common source of unnecessary latency is authentication.

Imagine every request entering the gateway and triggering:

API request → database lookup → user lookup → permission lookup → continue

Even a relatively fast database query becomes expensive when it happens on every request.

For high-frequency AI traffic, authentication data that rarely changes should generally be cached where appropriate.

I would measure:

Token verification time
User lookup time
Permission lookup time
Cache hit rate
Cache miss latency
External identity-provider calls

If a cache hit takes 2ms but a cache miss takes 80ms, you immediately have something useful to investigate.

The key is not to remove authentication. It is to avoid unnecessary synchronous work on every request.

3. Synchronous logging can become a hidden bottleneck

Logging looks harmless until the gateway starts doing too much of it.

A request may trigger:

Request logging
Token accounting
Cost calculation
Audit logging
Trace creation
Database writes
Metrics
Security events

If the gateway waits for those operations before forwarding the request, the latency adds up quickly.

For example:

Provider request → write audit record → wait for database → continue.

is very different from:

Provider request → enqueue audit event → continue

For latency-sensitive traffic, telemetry that does not affect the routing decision should generally be designed so it doesn't unnecessarily block the request path.

This does not mean turning off observability. It means separating decision-critical work from record-keeping work.

Modern gateway designs commonly expose separate gateway processing and provider timing, allowing engineers to distinguish between the two.

4. Policy checks can become surprisingly expensive

Authentication usually isn't the only gateway logic.

Production AI gateways may also check:

Rate limits
Model permissions
Organization limits
Token budgets
Prompt policies
Data-loss rules
Geographic restrictions
Model routing rules
Content classification

One rule might take milliseconds.

Ten rules involving external services can become a different problem.

The biggest mistake is running these checks serially:

Check A → Check B → Check C → Check D

If each one takes 20ms, you've already created an 80ms delay before the model receives the request.

Independent checks should run in parallel.

Caching is also useful for decisions that do not change on every request. Recent gateway benchmarking work emphasizes measuring identity, classification, policy evaluation, and audit operations separately because their latency characteristics are different.

5. Retries can explain a “mysterious” 400ms

This is one of the first things I check when latency suddenly jumps.

Suppose the normal provider request takes 700ms.

A temporary connection failure occurs.

The gateway waits 100ms and retries.

The second request succeeds.

Now the user sees something closer to:

100ms retry delay + 700ms provider request

and possibly additional connection overhead.

The gateway may still report the request as successful.

From an uptime dashboard, everything looks fine.

From the user's perspective, the application feels slow.

That is why I track:

Retry count
Retry reason
Retry delay
Provider selected
Fallback provider
Total provider attempts
Time spent before each attempt

A retry should never be invisible when debugging latency.

6. Streaming can expose another problem: buffering

For chat applications, I care much more about time to first token (TTFT) than total response time.

If the model begins generating after 500ms but the gateway buffers the response before sending anything to the browser, the user may see a blank screen for much longer.

The provider could already be producing tokens while the gateway is waiting.

So I measure two separate values:

Provider TTFT

and

Client-visible TTFT

If provider TTFT is 500ms but the browser receives the first token at 850ms, the missing 350ms is somewhere between the provider and the client.

That points toward gateway buffering, middleware, compression, transformations, or streaming configuration rather than model inference.

For interactive AI applications, this distinction is critical because users perceive responsiveness from the first visible output, not from when the server finishes generating the complete answer.

7. Don't benchmark the gateway against a fake request

Another mistake is testing the gateway against a mock provider and treating the resulting latency as production latency.

A mock upstream is useful for measuring the performance of pure proxies. It is not enough for understanding the real user experience.

Real AI requests include:

Network distance
Provider queueing
Model processing
Prompt size
Output length
Streaming behavior
Provider variability

The fair comparison is:

Direct provider request vs gateway → same provider

under the same concurrency and workload.

That tells you what the gateway actually costs.

Benchmarks from current AI gateway implementations commonly put gateway-specific processing in the single-digit to low-tens-of-milliseconds range. However, the exact result depends heavily on architecture, concurrency, connection handling, and what the gateway does inline.

A practical debugging checklist

If I saw a consistent 400ms increase, this is the order I would investigate:

First: Compare direct and gateway requests using the same provider.
Second: Check p50, p95, and p99 rather than only averages.
Third: Measure gateway processing time separately from provider latency.
Fourth: Check connection reuse and TLS handshakes.
Fifth: Measure calls to authentication and external dependencies.
Sixth: Check synchronous database, logging, and audit operations.
Seventh: Measure policy and classification latency.
Eighth: Inspect retries and provider fallback behavior.
Ninth: Compare provider TTFT with client-visible TTFT.
Tenth: Repeat the test under realistic concurrency.

The goal is not to make the gateway “fast” in the abstract. The goal is to identify the exact operation consuming the latency budget.

What a reasonable gateway latency budget looks like

There is no universal number because the correct budget depends on the application.

A 30ms gateway overhead may be irrelevant for a request that takes 3 seconds to generate an answer.

The same 30ms can matter a lot for an application where the complete response is expected in under 100ms.

For a practical production target, I would establish a gateway-specific p95 budget and continuously measure against it, rather than relying on a one-time benchmark.

For example:

Component	Example Target
Gateway processing	<10–20ms
Authentication	<5ms warm
Policy evaluation	<10ms
Audit/logging	Non-blocking
Connection reuse	Expected
Retry rate	Near zero normally
Client-visible TTFT	Track separately

These are engineering targets, not universal standards. The right values depend on workload and architecture.

Conclusion

An AI gateway adding 400ms to every request is not something I would accept as “the cost of having a gateway.” A properly measured gateway should let you separate its own processing from the much higher and more variable cost of model inference. Current gateway benchmarks and implementations generally show that the proxy layer itself can operate in milliseconds, which means a persistent 400ms increase is worth investigating.

The practical fix is to stop treating the request as a single number. Trace the connection, authentication, policy checks, routing, provider call, retries, streaming, and logging independently.

Once those timestamps are visible, the missing 400ms usually stops being mysterious.

The gateway isn't necessarily the problem.

The problem is the work happening inside the gateway that you haven't measured yet.

AI Gateways the Dev Communities Never Mention — But Absolutely Should

Harsh Raval — Tue, 01 Sep 2026 16:53:04 +0000

If you’re building with multiple AI models and still wiring OpenAI, Anthropic, Google, and open-source models directly into every application, you’re probably creating the same infrastructure problems over and over: different APIs, scattered API keys, unpredictable costs, provider outages, rate limits, and almost no clean way to see which model is actually being used. An AI gateway puts a control layer between your application and model providers, giving developers a consistent interface for routing, fallbacks, observability, caching, rate limits, and cost management.

What Is an AI Gateway?

An AI gateway is essentially a proxy layer for AI applications.

Instead of your application communicating separately with every model provider, it sends requests through one gateway:

Your App → AI Gateway → AI Model Providers

The gateway can then decide where each request should go.

For example, a simple chatbot might use a lower-cost model for routine questions and automatically send more demanding requests to a stronger reasoning model. If one provider becomes unavailable, the gateway can also route traffic to another provider without requiring changes throughout your application.

That makes AI gateways particularly useful once an application moves beyond a simple proof of concept.

The important distinction is that an AI gateway doesn't make the underlying model smarter. It solves the infrastructure and operations problems associated with using models.

AI Gateways for Developers Building With Multiple AI Models

If you care about infrastructure ownership, customization, data control, or running the gateway inside your own environment, these three deserve much more attention.

1. LiteLLM

Best for: developers who want an open-source, self-hosted AI gateway with broad model support.

LiteLLM is one of the most practical choices when you don't want your application tightly coupled to one AI provider.

Its main idea is straightforward: provide developers with a consistent API for communicating with many different LLM providers. The LiteLLM proxy can handle authentication, logging, rate limits, cost tracking, routing, retries, and fallbacks.

That becomes valuable when your application starts using several models.

Instead of building separate integrations for every provider, your application can communicate with LiteLLM while the gateway handles the provider-specific details behind the scenes.

It also supports self-hosting, which matters for teams that want more control over where requests, credentials, and operational data are handled.

Why developers should consider it:

Open-source gateway
Supports 100+ LLM providers
OpenAI-compatible interface
Routing and fallback support
Spend tracking and budgets.
Rate limiting
Self-hosting options

The biggest advantage isn't simply the number of supported models. It's the ability to change models without forcing your application architecture to change with them.

2. Portkey

Best for: teams that need governance, observability, and controls around AI requests.

Portkey approaches the gateway problem from a slightly different angle.

Instead of focusing solely on model routing, it emphasizes the operational layer surrounding AI applications. That includes observability, routing, retries, caching, guardrails, and controls that become increasingly important as multiple developers and applications start sharing AI infrastructure.

This makes it particularly interesting for organizations where the question isn't just:

"Which model should this request use?"

but also:

"Who can use which model, how much can they spend, and what happens when something goes wrong?"

Portkey can therefore fit teams that need more centralized governance around AI usage.

It's also worth considering when developers want gateway functionality without having to build every operational component themselves.

Why it stands out:

AI request observability
Routing and fallbacks
Guardrails
Cost and usage controls
Centralized AI infrastructure
Governance-focused architecture

For a small experiment, this can feel like more infrastructure than necessary. For a growing AI platform, that same structure can prove surprisingly useful.

3. Envoy AI Gateway

Best for: infrastructure teams already familiar with Envoy and cloud-native networking.

Envoy AI Gateway is the option I'd look at when the AI gateway needs to fit naturally into an existing cloud-native infrastructure stack.

The underlying idea is different from simply adopting an AI-focused SaaS dashboard. Instead, AI traffic becomes part of the broader networking and gateway architecture that infrastructure teams may already understand.

That makes it particularly relevant for organizations running Kubernetes, service meshes, microservices, or sophisticated API infrastructure.

The advantage here is architectural consistency.

If your infrastructure team already thinks in terms of gateways, policies, routing, authentication, and traffic management, introducing AI-specific routing through an Envoy-based approach can make more sense than adding an entirely separate operational system.

Why it deserves attention:

Cloud-native architecture
Fits modern microservice environments
Useful for Kubernetes-oriented teams
AI-aware traffic management
Familiar gateway concepts for infrastructure engineers

It's not necessarily the easiest starting point for a solo developer. Its appeal grows as AI traffic becomes an increasingly significant part of a larger infrastructure platform.

Not every team wants to operate another gateway server.

If you want less infrastructure maintenance and faster adoption, these managed options deserve a closer look.

4. OpenRouter

Best for: developers who want convenient access to many models via a single API.

OpenRouter solves one of the most obvious problems in multi-model development: having to integrate and maintain numerous provider APIs separately.

It provides a unified interface for accessing models from different providers, making it easier to experiment with models without repeatedly rewriting application integrations.

This makes OpenRouter particularly useful during experimentation.

You might start with one model, discover that another performs better for coding, and find a third is more economical for simpler requests. A unified gateway reduces the friction involved in testing those alternatives.

The trade-off is that you are relying on a managed intermediary rather than owning the gateway infrastructure yourself.

Best fit: developers who prioritize model variety and convenience over running their own gateway stack.

5. Cloudflare AI Gateway

Best for: teams already using Cloudflare or applications that benefit from edge infrastructure.

Cloudflare AI Gateway takes the gateway concept and connects it with Cloudflare's broader infrastructure ecosystem.

It provides features such as analytics, logging, caching, rate limiting, retries, and model fallback. Cloudflare's current documentation also supports routing requests to third-party providers, such as OpenAI, Anthropic, and Google, via its API.

That combination is useful because developers don't necessarily need to build another dedicated proxy service to gain visibility and control over traffic.

For example, caching can reduce repeated model calls, while rate limiting can prevent unexpected traffic spikes from turning into unexpected AI bills.

Cloudflare also supports web search capabilities through its AI Gateway integrations, applying gateway features such as logging, caching, rate limiting, and guardrails to those requests.

Best fit: applications already living in the Cloudflare ecosystem or teams looking for a managed edge-oriented AI gateway.

6. Helicone

Best for: developers who care deeply about AI observability and understanding what happens inside production AI applications.

Helicone is especially interesting because observability is central to its value proposition.

Once an AI application reaches production, simply knowing that an API request succeeded isn't enough.

You eventually want to know:

Which model handled the request?
How many tokens were consumed?
How much did the request cost?
Which users or features are generating the most traffic?
Where are latency problems occurring?
Which prompts are failing?
How is usage changing over time?

That's where an observability-focused gateway becomes useful.

Helicone can give development teams a clearer operational picture of their AI traffic, rather than leaving usage information scattered across individual provider dashboards.

Best fit: teams where debugging, monitoring, cost visibility, and production analytics are more important than simply accessing the largest number of models.

AI Gateway Comparison: Which One Makes Sense?

AI Gateway	Best For	Deployment	Key Strength
LiteLLM	Developers & platform teams	Self-hosted / managed	Multi-provider routing
Portkey	Production teams	Managed / self-hosting options	Governance & controls
Envoy AI Gateway	Cloud-native teams	Infrastructure-focused	AI traffic management
OpenRouter	Developers experimenting with models	Managed	Broad model access
Cloudflare AI Gateway	Cloudflare users	Managed	Edge + observability
Helicone	AI product teams	Managed	Observability

The important thing is that there isn't one universally best AI gateway.

The right choice depends on what problem you're trying to solve.

If infrastructure ownership is the priority, LiteLLM is a strong starting point. If governance and centralized controls matter more, Portkey is worth investigating. Cloud-native infrastructure teams may naturally gravitate toward Envoy AI Gateway.

On the managed side, OpenRouter makes multi-model experimentation straightforward, Cloudflare AI Gateway makes sense for teams already invested in Cloudflare, and Helicone is particularly compelling when observability is the biggest gap.

When Do You Actually Need an AI Gateway?

You don't need an AI gateway if you're building a tiny application that makes occasional requests to one model provider.

Direct API access is often simpler in that situation.

An AI gateway starts becoming more valuable when you have:

Multiple model providers
Different models for different workloads
High or unpredictable AI spending
Provider rate limits or reliability concerns
A need for centralized logging
Multiple developers or applications sharing AI infrastructure
Requirements around access control or governance
A need to switch models without rewriting application code

The turning point is usually operational complexity.

Once your application needs routing, fallback, cost tracking, caching, and centralized controls, you're effectively building gateway functionality yourself if you don't use one.

The Bigger Reason AI Gateways Matter

AI development is moving away from the idea that one application equals one model.

Production applications increasingly mix models according to capability, cost, latency, availability, and workload.

A simple request doesn't necessarily need your most expensive model. A complex reasoning task may justify one. A provider outage shouldn't necessarily bring down the entire application.

That is where the gateway layer becomes strategically useful.

It gives developers a place to manage those decisions without scattering provider-specific logic throughout the application.

And that's why these tools deserve more attention from developer communities. The interesting part isn't simply connecting to another AI model.

It's building an AI system that remains manageable after the prototype becomes a real product.

Conclusion

AI gateways are becoming an important infrastructure layer for multi-model applications, but choosing one shouldn’t start with a feature checklist. Start with the problem you need to solve:

LiteLLM: Best when self-hosting and infrastructure control are priorities.
Portkey: A strong choice when governance and operational controls are central.
Envoy AI Gateway: Ideal when AI traffic needs to fit into a cloud-native architecture.
OpenRouter: Best for convenient access to multiple AI models.
Cloudflare AI Gateway: Useful for managed, edge-oriented AI infrastructure.
Helicone: Best when observability and monitoring are the top priorities.

Ultimately, the best AI gateway is the one that solves your specific infrastructure challenge, not the one with the longest feature list.

FAQs

1. What is an AI gateway?

An AI gateway is a proxy layer between an application and AI model providers. It can centralize model routing, authentication, logging, caching, rate limiting, fallbacks, and cost management through a common interface.

2. Is LiteLLM a good self-hosted AI gateway?

Yes. LiteLLM is designed to provide a unified interface across many LLM providers, and its proxy supports features such as routing, authentication, logging, rate limiting, and spend management.

3. What is the difference between OpenRouter and LiteLLM?

OpenRouter is a managed gateway that provides convenient access to many models, while LiteLLM is particularly suited to teams that want to run and control the gateway infrastructure themselves.

4. When should a developer use an AI gateway?

Use one when an application needs multiple AI providers, model fallbacks, centralized observability, cost controls, caching, rate limits, or the ability to change models without rewriting application integrations.

5. Which AI gateway is best for production?

There is no single best option. LiteLLM is well suited to self-hosted infrastructure, Portkey to governance-focused deployments, OpenRouter to manage multi-model access, Cloudflare AI Gateway to Cloudflare-based applications, Helicone to observability, and Envoy AI Gateway to cloud-native infrastructure.

Best Design Apps I Would Give My Younger Self Starting in Design

Harsh Raval — Mon, 31 Aug 2026 17:25:44 +0000

If I could go back to my first year in design, I would spend far less time asking "Which design app is the best?" and more time asking "What am I actually trying to create?" Beginners often jump between apps, collect tutorials, and feel behind because professional designers seem to use complicated software from day one. The truth is that different apps solve different design problems: some make social graphics easier, some teach you photo editing, some build vector skills, while others let you draw or experiment in 3D. Current design tool comparisons still clearly show this split, with Canva standing out for quick layouts, Photoshop for pixel-based work, Illustrator for vector design, and Procreate for illustration.

The design apps I would learn first

If I were starting again, I would not try to master ten applications at once. I would build a small toolkit around the type of work I wanted to create.

For most beginners, my starting order would be:

Canva — learn composition and everyday visual design.
Adobe Express — practice fast content creation.
Desygner — understand template-based layouts and branded content.
Adobe Photoshop — develop real image-editing skills.
Adobe Illustrator — learn vector design, logos, and typography.
Procreate — develop illustration and drawing skills.
Tinkercad — experiment with basic 3D thinking.

That order isn't about declaring one app "the winner." It is about gradually increasing your control over your work.

Graphic and Social Media Apps

1. Canva

Best for: Beginners, social media graphics, presentations, marketing visuals, and quick layouts.

Canva is where I would tell my younger self to start because it removes some of the technical friction that can overwhelm a beginner. You can concentrate on hierarchy, spacing, typography, images, alignment, and color without first learning a complicated interface.

That matters because design fundamentals are more valuable than knowing where every button lives.

I would use Canva to create Instagram posts, LinkedIn graphics, simple presentations, banners, thumbnails, and campaign concepts. Current 2026 comparisons continue to position Canva strongly for layout-driven and marketing design.

What I would learn: spacing, alignment, visual hierarchy, typography, and consistency.

What I wouldn't do: rely on templates forever. Once you understand why a layout works, start creating your own.

2. Adobe Express

Best for: Fast social graphics, promotional content, resizing, and quick photo edits.

Adobe Express would be my second stop because it sits between beginner-friendly design and the wider Adobe ecosystem. It is useful when you need to produce content quickly without opening a more complex professional application.

I would use it for social posts, flyers, simple promotional graphics, and quick edits.

The important lesson here is speed without sacrificing basic design principles. A fast workflow is valuable, but only when the result is still readable and purposeful. Adobe Express is currently positioned as a quick, accessible option for social graphics and image editing.

3. Desygner

Best for: Templates, marketing materials, social content, and brand-focused designs.

Desygner is another useful beginner-friendly option, particularly if your work involves repeated marketing materials.

I would recommend it less as a tool to "master" and more as a way to understand how reusable design systems work. Instead of creating every graphic from scratch, you begin thinking about templates, brand consistency, dimensions, and variations.

That is a surprisingly important professional skill.

Professional and Advanced Tools

Once the basics make sense, this is where I would invest serious time in learning.

4. Adobe Photoshop

Best for: Photo editing, image manipulation, compositing, retouching, and raster graphics.

Photoshop is one of the apps I wish I had understood earlier, not because every beginner needs it immediately, but because learning it teaches you how digital images actually work.

Layers, masks, selections, blending, adjustment layers, smart objects, and compositing become much easier once you stop thinking of Photoshop as a collection of buttons and start thinking in terms of controlling pixels.

For example, if you're designing a social campaign, Photoshop can help you create and manipulate the underlying imagery before bringing the finished assets into another workflow. Current professional design guides still place Photoshop firmly in the raster, photo-editing, and compositing category.

My advice: don't try to learn every feature. Learn layers, masks, selections, adjustment layers, typography, and non-destructive editing first.

5. Adobe Illustrator

Best for: Logos, icons, branding, vector illustrations, packaging, and scalable graphics.

If Photoshop teaches you about pixels, Illustrator teaches you to think in vectors.

That distinction completely changed how I understood professional graphic design.

A logo shouldn't become blurry simply because it is enlarged. A vector-based design can scale while maintaining clean shapes and edges. That's why Illustrator remains particularly important for identity systems, logos, icons, diagrams, packaging, and other scalable artwork.

If I could give my younger self one Illustrator lesson, it would be this:

Learn paths before chasing effects.

Pen-tool control, anchor points, curves, shapes, typography, and alignment will take you much further than knowing dozens of decorative effects.

6. Procreate

Best for: Digital illustration, sketching, lettering, painting, and iPad-based creative work.

Procreate belongs on this list because not every designer should begin with a mouse and a grid. Sometimes you need to draw.

For illustrators, lettering artists, concept designers, and anyone who thinks visually through sketching, Procreate can become a natural creative workspace. It is particularly strong on iPad with Apple Pencil, and current design roundups continue to place it among the leading illustration tools.

I would use Procreate to explore ideas rather than force everything into perfectly geometric shapes.

Sketch the logo.
Draw the character.
Experiment with lettering.

Then take the useful idea into Illustrator or Photoshop when the project requires a more structured production workflow.

That combination of freehand creativity + professional refinement is more valuable than trying to make one application do everything.

7. Tinkercad

Best for: Beginner 3D design, simple models, and learning spatial thinking.

Tinkercad might seem unusual in a graphic design list, but I would absolutely show it to my younger self.

Why?

Because design isn't always flat.

Even basic 3D experimentation teaches you to think about depth, proportion, perspective, dimensions, and how objects relate to one another in space.

You don't need to become a 3D artist. Spend some time building simple objects, and you'll start looking at visual problems differently.

That kind of cross-disciplinary thinking can make a designer better at everything from product visuals to illustrations and presentations.

What I Would Actually Learn First

If I were starting from zero today, I wouldn't spend six months watching tutorials for every application.

I'd build projects.

Month 1: Canva or Adobe Express

Create social posts, posters, thumbnails, and simple presentations.

Month 2: Photoshop

Recreate photo compositions and practice selections, masks, layers, and adjustments.

Month 3: Illustrator

Create logos, icons, simple illustrations, and typography-based designs.

Month 4: Procreate or Tinkercad

Explore either illustration or 3D depending on your interests.

The goal isn't to collect software skills. The goal is to understand why a design works.

That distinction becomes important as you progress. A designer who knows five apps but doesn't understand hierarchy will struggle. A designer who understands hierarchy, typography, spacing, contrast, composition, and audience can learn a new application much faster.

Which design app should a beginner choose?

For the easiest starting point: Canva.
For quick social content: Canva or Adobe Express.
For photo editing: Photoshop.
For logos and vector graphics: Illustrator.
For drawing and illustration: Procreate.
For beginner 3D: Tinkercad.

There isn't one application that replaces all the others. Even current comparisons emphasize that the right choice depends on the job, not simply on picking the software with the longest feature list.

Conclusion

If I could give my younger self one piece of design advice, it would be simple: stop trying to become an expert in the software and start becoming an expert at solving visual problems.

Canva would have helped me understand layouts faster. Photoshop would have taught me image control. Illustrator would have strengthened my understanding of vectors and branding. Procreate would have encouraged more experimentation, while Tinkercad would have pushed me to think beyond two dimensions.

The best design app isn't necessarily the most powerful one. It's the one that helps you understand the kind of designer you want to become.

FAQs

1. What is the best design app for beginners?

Canva is a strong starting point because beginners can practice layouts, typography, spacing, and visual hierarchy without a steep technical learning curve.

2. Should I learn Photoshop or Illustrator first?

Learn Photoshop first if you are interested in photo editing and raster graphics. Start with Illustrator if your goal is logos, branding, icons, or vector illustration.

3. Is Canva enough to become a professional designer?

Canva is useful for learning fundamentals and producing everyday marketing designs. Still, professional designers often need more specialized tools for advanced photo editing, vector artwork, illustration, UI design, or print production.

4. Is Procreate useful for graphic designers?

Yes. Procreate is particularly useful for illustration, sketching, lettering, and creating original artwork that can later be refined in other design applications.

5. How many design apps should a beginner learn?

Start with one primary application and learn it through real projects. Add specialized tools only when your projects require capabilities your current app cannot provide.

Best UI/UX Design Tools I Keep Coming Back to as a Designer

Harsh Raval — Mon, 24 Aug 2026 16:45:48 +0000

If you’re a designer, you’ve probably had the same problem I’ve had: there are dozens of UI/UX design tools promising to make your workflow faster, but switching between them often creates more friction than it removes. The real question isn’t “Which design tool is the most popular?” It’s which tool actually helps me think, design, prototype, collaborate, and ship better work? After working across different design workflows, I’ve found that no single platform does everything perfectly. Instead, the most effective setup combines dependable core design software with specialized tools for prototyping, user flows, collaboration, and AI-assisted UI generation.

The UI/UX Design Tools I Keep Coming Back To

My current toolkit falls into four practical categories:

● Core Design and Layout: Figma, Penpot, Sketch
● Prototyping and Motion: ProtoPie, Framer
● Whiteboarding and User Flows: FigJam, Miro
● AI-Assisted UI Generation: Uizard, Moda.app

The important distinction is that these tools solve different problems. Figma or Sketch can handle interface design, but a motion-heavy prototype may be better suited to ProtoPie. Likewise, an AI interface generator can help explore ideas quickly, while a whiteboarding tool is better for understanding the problem before designing the solution.

Quick Comparison of the Best UI/UX Design Tools

Tool	Category	Best For	Main Strength	Potential Limitation
Figma	Core Design	UI design, systems, collaboration	Powerful browser-based workflow	Can feel complex for beginners
Penpot	Core Design	Open-source collaborative design	Open-source and flexible	Smaller ecosystem
Sketch	Core Design	Mac-based product design	Mature UI design workflow	Primarily focused on Apple platforms
ProtoPie	Prototyping	High-fidelity interactions	Advanced interaction logic	More specialized learning curve
Framer	Prototyping/Web	Interactive websites and prototypes	Design-to-web workflow	Less focused on traditional UX documentation
FigJam	Whiteboarding	Workshops and user flows	Easy visual collaboration	Not a replacement for a full UI editor
Miro	Whiteboarding	Research, mapping and workshops	Extremely flexible canvas	Large boards can become messy
Uizard	AI UI Generation	Rapid interface concepts	Fast idea generation	AI output still needs design refinement
Moda.app	AI UI Generation	Exploring UI concepts with AI	Speeds up early-stage ideation	Best used alongside, not instead of, design fundamentals

Core Design and Layout

1. Figma

Figma is the tool I recommend first for anyone who wants a versatile environment for modern UI/UX design.

Its biggest advantage is that design, prototyping, components, libraries, comments, and collaboration can live in the same workflow. That matters when multiple designers, developers, product managers, and stakeholders need to work around the same product.

For UI work, Figma is particularly useful for:

● Responsive interface layouts
● Design systems
● Components and variants
● Wireframes
● High-fidelity mockups
● Interactive prototypes
● Developer handoff
● Collaborative reviews

What keeps me coming back is not simply the number of features. It is the reduced friction between designing an interface and getting feedback on it.

For larger product teams, that shared workflow can be more valuable than any individual feature.

Best for: Product designers, UX teams, agencies, startups, and collaborative design teams.

2. Penpot

Penpot stands out for its open-source approach to UI design.

It provides tools for interface design, prototyping, component development, and collaboration, while giving organizations more control over how the platform fits into their environment.

That makes Penpot especially interesting for teams that care about open standards, self-hosting possibilities, or reducing dependence on a single proprietary ecosystem.

I wouldn’t automatically replace an established Figma workflow with Penpot. But if you’re evaluating alternatives, Penpot deserves serious consideration.

Best for: Open-source advocates, organizations seeking more control, and teams evaluating alternatives to mainstream design platforms.

3. Sketch

Sketch has been around long enough to have influenced modern interface design workflows.

Its strength remains focused on product and interface design, particularly for designers working within Apple’s ecosystem.

Sketch offers a mature approach to:

● Interface design
● Symbols and reusable components
● Prototyping
● Design systems
● Developer handoff

It isn’t necessarily the obvious choice for every team today, particularly when cross-platform collaboration is a priority. But for designers who prefer a Mac-first environment and want a dedicated UI design application, Sketch remains worth considering.

Best for: Mac-based UI designers and established product design workflows.

Prototyping and Motion

4. ProtoPie

ProtoPie is where I would look when a normal click-through prototype isn’t enough.

Traditional prototypes can demonstrate navigation, but complex products often depend on gestures, animation, transitions, sensor-like interactions, and dynamic behavior.

ProtoPie focuses heavily on those details.

You can use it to explore interactions such as:

● Dragging
● Scrolling
● Swiping
● Advanced transitions
● Input-based interactions
● Motion behavior
● Micro-interactions

This makes it particularly useful when you’re trying to answer a question that static screens cannot answer:

“What will this interface actually feel like?”

Best for: Interaction designers, mobile product designers, and teams testing sophisticated interactions.

5. Framer

Framer sits somewhere between design, prototyping, and web publishing.

That makes it particularly useful when the thing you’re designing is a website rather than a complex application interface.

Framer is good for:

● Landing pages
● Marketing websites
● Interactive web prototypes
● Responsive layouts
● Animations
● Visual web design
● Publishing websites

The interesting part is the shorter distance between visual design and a functioning web experience.

For a designer working on marketing sites, portfolios, or product websites, that can dramatically simplify the workflow.

Best for: Web designers, marketers, freelancers, and designers building interactive websites.

Whiteboarding and User Flows

6. FigJam

FigJam is useful before the polished interface exists.

That distinction matters.

A common design mistake is jumping into a high-fidelity UI before understanding the problem. FigJam provides a flexible environment for brainstorming, workshops, journey mapping, user flows, research synthesis, and early planning.

I find it especially useful for:

● User journey maps
● Customer journeys
● Brainstorming
● Affinity mapping
● User flows
● Workshops
● Retrospectives
● Early product planning

Its biggest strength is simplicity: you can put ideas on a canvas without worrying about pixel-perfect UI.

Best for: UX workshops, product discovery, user flows, and collaborative planning.

7. Miro

Miro is another powerful whiteboarding platform, but its flexibility makes it useful beyond traditional design workshops.

A Miro board can become a research repository, customer journey map, product planning space, brainstorming canvas, or workshop environment.

It works particularly well when a project involves people outside the design team.

For example, researchers can bring findings into the same workspace where product managers map requirements and designers develop user flows.

The downside is also its strength: flexibility can create clutter. Without some structure, large boards can become difficult to navigate.

Best for: UX research, workshops, journey mapping, product planning, and cross-functional collaboration.

AI-Assisted UI Generation

8. Uizard

Uizard is useful when the goal is to move quickly from an idea to a visual interface concept.

Instead of starting every project from a blank canvas, AI-assisted tools can help provide initial direction.

Uizard is particularly useful for:

● Rapid wireframes
● UI concepts
● Early product ideas
● Mockups
● Brainstorming
● Turning rough concepts into interfaces

The important thing is how you use AI-generated output.

I wouldn’t treat the first generated screen as a finished design. It is better viewed as a starting point for design thinking.

A professional designer still needs to evaluate hierarchy, accessibility, usability, consistency, content, interaction patterns, and business requirements.

Best for: Fast concept development, early-stage ideation, and teams that want to visualize ideas quickly.

9. Moda.app

Moda.app belongs in the emerging category of AI-assisted design workflows.
Its value lies primarily in accelerating early exploration. Instead of manually exploring every possibility from scratch, designers can use AI to explore different interface directions.

That can be useful when you’re asking:

● What could this dashboard look like?
● Which layout might work better?
● How could this product concept translate into UI?
● What visual direction should I explore next?

The key is not to confuse generation speed with design quality.

AI can produce possibilities quickly, but deciding which possibility actually solves the user’s problem remains a design responsibility.

Best for: Early UI exploration, concept generation, and accelerating the first stage of visual ideation.

Which UI/UX Design Tool Should You Choose?

The answer depends on what you’re actually trying to accomplish.

● For complete UI/UX design: Figma is the strongest all-around choice.
● For open-source design workflows: Penpot is worth exploring.
● For Mac-focused interface design: Sketch remains a solid option.
● For advanced interaction design: ProtoPie is the specialist.
● For interactive websites: Framer makes more sense.
● For workshops and user flows: FigJam is simple and effective.
● For broad research and collaboration: Miro offers a highly flexible canvas.
● For fast AI-generated concepts: Uizard and Moda.app work well as lightweight wireframing software, letting you sketch out structure and hierarchy with AI assistance before moving into full UI design.

The mistake is choosing a tool because everyone else uses it. A better approach is to choose based on the job the tool needs to perform.

My Practical UI/UX Workflow

I rarely think of these tools as competitors.

A realistic workflow might look like this:

FigJam or Miro → Figma → ProtoPie/Framer → developer handoff

For AI-assisted exploration, I suggest inserting Uizard or Moda.app near the beginning when I need to generate or compare ideas quickly.

This approach works because each tool has a specific role.

The whiteboard helps me understand the problem.
The design tool helps me build the interface.
The prototyping tool helps me test behavior.
The AI tool helps me explore possibilities faster.

That separation prevents the common mistake of forcing one application to solve every design problem.

Conclusion

The best UI/UX design tool isn’t necessarily the one with the longest feature list. It’s the one that removes friction from the specific part of your workflow you’re working on.

For most product designers, Figma is the strongest all-rounder, while Penpot and Sketch offer credible alternatives for different environments. ProtoPie and Framer become valuable when interaction and web experiences matter. FigJam and Miro are better suited to the thinking and collaboration that happen before polished UI. Meanwhile, Uizard and Moda.app can accelerate early exploration without replacing fundamental design judgment.

My biggest takeaway after using different design workflows is simple: don’t build your toolkit around one “best” tool. Build it around the design problems you need to solve.

FAQs

1. What is the best UI/UX design tool for beginners?

Figma is usually the easiest starting point because it combines UI design, prototyping, components, and collaboration into a single environment. It also gives beginners room to progress into more advanced product design workflows.

2. Is Figma better than Sketch for UI/UX design?

For teams that prioritize browser-based collaboration and cross-platform workflows, Figma is generally more convenient. Sketch remains a strong option for designers who prefer a Mac-centered design environment.

3. What is the best tool for UI/UX prototyping?

It depends on prototype complexity. Figma works well for standard product prototypes, while ProtoPie is better suited to advanced interactions and motion. Framer is particularly useful for interactive web experiences.

4. Are AI UI design tools replacing UX designers?

No. AI-assisted tools can speed up ideation and generate interface starting points, but they don’t replace user research, product thinking, usability evaluation, accessibility decisions, information architecture, or experienced design judgment.

5. Should I use Figma, FigJam, and Miro together?

You can, but you don’t have to. Figma is better for interface design, while FigJam and Miro are primarily collaborative whiteboarding environments. Choose the combination that matches your team’s workflow rather than maintaining multiple tools simply because they are popular.

Elsierainee

Harsh Raval — Sat, 22 Aug 2026 08:51:58 +0000