DEV Community: Andre.devs

How Much Does It Cost to Hire a Web App Developer in 2026?

Andre.devs — Sat, 29 Aug 2026 09:00:00 +0000

The cost of hiring a web app developer can range from a small fee for a focused repair to thousands of dollars for a complete product.

That wide range is why asking, “What is your hourly rate?” is rarely enough.

A better question is:

What outcome do I need, and what must the developer handle to deliver it properly?

Start with the scope

A landing page and a SaaS application are both web projects, but they require completely different levels of work.

A simple website may only need:

A responsive interface
A contact form
Basic SEO
Analytics
Deployment

A web application may also require:

User registration and authentication
Different account roles and permissions
A database
Payments or subscriptions
Dashboards
File uploads
Email notifications
External APIs
Admin controls
Security rules
Mobile testing
Production deployment

Each additional layer increases the implementation, testing, and maintenance required.

Practical budget ranges

These are broad planning estimates, not guaranteed quotes.

Focused diagnosis or contained bug fix

Approximately $50–$500

This may include:

Finding why a form is not saving
Fixing a broken login or redirect
Repairing a database query
Correcting mobile responsiveness
Fixing a deployment problem
Troubleshooting an API integration

The cost depends heavily on whether the cause is already known.

A visible symptom such as an endless loading screen might be caused by authentication, environment variables, database permissions, an API failure, or loading-state code.

Landing page or small marketing website

Approximately $500–$2,000

This typically covers a focused website with:

Responsive design
Several content sections
Contact or lead forms
Basic integrations
SEO foundations
Analytics
Deployment

Custom animations, complex forms, copywriting, booking systems, and advanced integrations can increase the price.

Business website

Approximately $2,000–$8,000

A larger business website may include:

Multiple pages
A CMS
Blog or resource content
Lead management
Booking functionality
Customer accounts
Search or filtering
Several integrations
More extensive testing

The final cost depends on the number of unique page layouts and workflows, not only the number of pages.

Completing or repairing an AI-built app

Approximately $500–$3,000

Tools such as Lovable, Replit, and Base44 can produce an impressive application quickly.

However, an unfinished app may still need help with:

Authentication
Database structure
Supabase policies
Payments
Mobile layouts
Production configuration
Error handling
API connections
Deployment
Testing

Completing an organized AI-built app can be fast. Repairing one with duplicated logic, unclear prompts, or inconsistent data may take longer than expected.

Custom MVP

Approximately $2,000–$15,000 or more

A custom minimum viable product may include:

User accounts
Several user roles
A database
Payments
Dashboards
Messaging
Automations
Admin tools
Third-party APIs
Responsive design
Production deployment

The best approach is usually to launch one valuable user journey first and postpone secondary features.

Hourly versus fixed-price work

Both pricing methods can work, but they solve different problems.

Hourly pricing

Hourly pricing is useful when:

The cause of the problem is unknown
The requirements may change
The application was built by someone else
The developer must investigate before estimating
Several systems may be involved

The disadvantage is that the final cost is less certain until the investigation is complete.

Fixed-price work

Fixed pricing works best when:

The deliverable is clearly defined
The required pages and workflows are known
Acceptance criteria are written
Dependencies and exclusions are understood
Both sides agree on what “complete” means

A fixed price without a clear scope can create disagreements and rushed work.

Milestone pricing

For larger projects, milestones are often safer.

A project could be divided into:

Discovery and specification
Core user journey
Database and integrations
Responsive testing
Production deployment
Handover and support

Each milestone creates something that can be reviewed before the next payment decision.

What increases development cost?

The largest cost factors usually include:

Multiple user roles
Authentication and permissions
Payments and subscriptions
Database migrations
Sensitive or private data
External APIs
Email or notification systems
File storage
Complex dashboards
Custom animations
Mobile responsiveness
Accessibility requirements
Admin tools
Production troubleshooting

The condition of an existing project also matters.

A well-organized application with a reproducible bug is easier to estimate than an application with no documentation, several unfinished features, and different behavior in Preview and production.

Do AI builders make development cheaper?

They can.

Lovable, Replit, Base44, and similar platforms reduce the time required for scaffolding, interface creation, and repetitive code.

But they do not remove the need for:

Secure authentication
Database permissions
Reliable payments
Data validation
Error handling
Production configuration
Mobile testing
Deployment
Maintenance

The real cost advantage comes from combining fast tools with careful engineering and testing.

How to compare developer quotes

Do not compare quotes using price alone.

Ask what each quote includes:

What exactly will be delivered?
What is excluded?
How many revisions are included?
Who owns the code and accounts?
Is mobile testing included?
Is deployment included?
Are database changes included?
Are third-party subscriptions separate?
What happens after launch?
How will completion be verified?

A cheap quote can become expensive when it only covers the visible interface and excludes the database, integrations, deployment, or live testing.

How to receive a more accurate estimate

Before contacting a developer, prepare:

The platform being used
A public or Preview link
The main user journey
What currently works
What is broken or missing
Required integrations
Your desired deadline
Screenshots or error messages
What you will accept as completed

Never send passwords, production secrets, or private customer data in an initial message.

Final thought

The best developer is not necessarily the person offering the lowest hourly rate.

Look for someone who understands the complete journey from the interface to authentication, database rules, integrations, mobile behavior, and production deployment.

A focused paid diagnosis can also save money when the scope is uncertain. It replaces guesses with a reproducible problem, a repair plan, and a more credible estimate.

I published a more detailed version of this pricing guide here:

Web App Developer Cost in 2026: Complete Pricing Guide

You can also view my web app development and troubleshooting services here:

Andre.Devs Web Development Services

How I Fixed a Replit App Stuck After Clerk Authentication

Andre.devs — Thu, 27 Aug 2026 09:00:00 +0000

An authentication problem is not always a failed login.

I recently worked on a multi-application Replit proof of concept that used Clerk for authentication. The intended journey was simple:

Open the public landing application
Sign in once with Clerk
Continue into a protected comparison tool
Avoid being asked to authenticate again

Instead, the application could remain stuck on an endless loading screen after sign-in.

The symptoms

The problem appeared in more than one way:

The application displayed an endless spinner after authentication
An affected account could receive a message saying it did not have a valid user record
Preview and the published application behaved differently
More than one Replit application participated in the sign-in journey
The final protected route depended on a successful redirect

The client and product are intentionally unnamed here. The investigation and verified result are real, but private application details and credentials remain confidential.

Authentication had succeeded

The important clue was that Clerk had already authenticated the user.

This meant the problem was not simply an incorrect password or failed login. Authentication only confirmed the user's identity. The application could still reject that authenticated user if it expected:

A separate application user record
An accepted invitation
A particular role or permission
An allowed domain
A valid redirect destination
Matching environment values

This distinction prevented me from treating every part of the problem as a Clerk login failure.

Separating Preview from production

Preview and production should be treated as separate environments when diagnosing Replit applications.

A Preview session may use a different domain, environment configuration, callback URL, or deployment state from the published application.

I tested the shortest important live journey first:

Open the public landing page
Sign in
Resolve the application user
Redirect to the protected tool
Confirm that the destination loads

Testing this narrow path made it easier to identify whether the live application was improving without allowing a Preview-only issue to hide the result.

Checking every layer

I followed the authentication journey one transition at a time.

Clerk domain configuration

I checked that the relevant Replit domains were recognized by the authentication setup. A missing or outdated domain can allow part of the login process to work while breaking the callback or redirect.

Environment values

Because the journey crossed more than one Replit application, the required Clerk values needed to exist in both application environments.

I confirmed that the expected values were present and that their names matched what each application expected.

User provisioning

I reviewed the invitation and application-user path.

A person can have a valid Clerk session but still lack the internal user record, role, or invitation required by the product.

The test invitation was refreshed so the account could be evaluated cleanly instead of inheriting an earlier failed state.

Redirect handling

I traced where the user was sent after authentication and checked whether the destination application could complete its own access checks.

For the demonstration journey, unnecessary redirects were removed so the route focused on the real goal: authenticate once and reach the comparison tool.

Republishing

After changing the configuration, the applications were republished.

This step mattered because testing an older deployment would have produced misleading results even if the settings had already been corrected elsewhere.

The result

The published application stopped hanging on the loading screen and the live journey reached the intended comparison workflow.

That confirmed the production route was no longer blocked by the same authentication transition failure.

Preview still required its own domain handling, so I kept it as a separate follow-up instead of claiming that every environment problem had been resolved.

Protecting a working production route was more important than making unnecessary changes just to force Preview and production into the same diagnosis.

My checklist for similar Replit problems

When a Replit application gets stuck after login, I now check:

Did the authentication provider create a valid session?
Does the product require its own user record?
Is the invitation still valid?
Does the account have the correct role or permission?
Are all public and Preview domains allowed?
Are callback and redirect URLs correct?
Do all connected Replit applications have the required secrets?
Do environment-variable names match the application code?
Has the application been republished since the configuration changed?
Does the loading state end when an access check fails?

The main lesson is that a spinner is only a symptom.

The actual failure may exist between identity, user provisioning, domain validation, environment configuration, redirects, and the final protected route.

The fastest way to find it is to test one clean account through one short, repeatable journey before expanding into additional roles and environments.

Read the complete Replit and Clerk authentication case study

View my Replit development and troubleshooting services

How I Diagnosed a Base44 CRM Migration That Appeared to Lose Data

Andre.devs — Mon, 24 Aug 2026 14:53:25 +0000

A CRM migration can appear successful while important data is still missing.

That was the problem I faced while diagnosing a Base44 CRM migration. The application loaded, some records were present, and the import process had completed without an obvious failure. However, contacts, leads, reminders, candidates, and their relationships did not look complete.

Instead of immediately changing the importer, I investigated what had actually been exported and processed.

The first clue: the archive was incomplete

I inspected the migration archive and found only six entries. The main data file was TeamMember.json, while the manifest identified the export as the team_members phase.

The archive did not contain the expected files for:

Contacts
Leads
Reminders
Candidates
Other related CRM records

This changed the diagnosis completely.

The importer had not randomly lost the data. It had processed the information it received, but several migration phases had never been included in that archive.

Why the problem was misleading

From the user interface, the symptoms looked like an application bug:

Some records appeared while others did not
Relationships between profiles and team members were incomplete
Screens displayed different totals
The migration itself appeared to have finished

It would have been easy to blame the dashboard or rewrite the importer. That would not have fixed the actual problem.

The real issue was an incomplete, single-phase export.

Completing and verifying the migration

After identifying the missing phases, I completed the remaining migration jobs and verified their status.

The completed migration included:

525 per-user jobs
69 all-user jobs
No jobs left running, queued, or pending

I then checked the live records instead of relying only on the migration status.

The verified totals were:

20,949 contacts
16,344 leads
3,096 team members
10,393 reminders
1,522 candidates

Completing a job is not enough proof that a migration is correct. The destination data must also be counted and inspected.

Repairing broken relationships

One remaining issue involved relationships between profile records and team-member records.

Some records could not be matched using only the primary email address. I added a safer matching process that also considered secondary and additional email fields.

After repairing the relationships, I checked for:

Duplicate records
Orphaned records
Incorrect profile-to-team-member links
Screens still referencing old or temporary data
Security rules accidentally changed during the repair

The final verification found zero duplicate records and zero orphaned records. The application screens were connected to the live tables, and the existing row-level security rules remained intact.

What I learned

Here are the main lessons I would apply to any CRM or SaaS data migration:

1. Inspect the source archive first

Before rewriting an importer, confirm that every expected entity and migration phase exists in the source files.

2. Separate export problems from import problems

If data never entered the archive, the importer cannot restore it. These are two different failure points and should be investigated separately.

3. Verify live totals

A “completed” status only confirms that a process stopped. Compare the source and destination counts for every important entity.

4. Validate relationships, not only records

Having every contact and team member in the database is not enough if the links between them are broken.

5. Use fallback matching carefully

Secondary email fields can help repair relationships, but matches should be deterministic and checked for duplicates.

6. Preserve security during repairs

Migration fixes should not require weakening authentication or row-level security. Always verify access controls after changing production data.

A practical migration checklist

Before declaring a migration complete, I now check:

Are all expected files present?
Are all migration phases represented?
Did every job finish?
Do source and destination totals match?
Are duplicate and orphan counts zero?
Are relationships correctly connected?
Are application screens reading from the live tables?
Are authentication and security rules still working?

The most important lesson is simple: diagnose the data pipeline before changing the application.

Sometimes the visible bug is only the final symptom of an incomplete export several steps earlier.

Read the complete Base44 CRM migration case study

View more of my web app, SaaS and automation work