Building a Free Immigration Cost Calculator: Technical Decisions and Trade-offs

Immigration to the United States is expensive. Between USCIS filing fees, attorney costs, medical exams, and miscellaneous expenses, applicants often face bills ranging from $5,000 to over $30,000 depending on their visa category. Yet most people start the process with little understanding of the total cost.

I recently worked on building a free cost estimation tool for EB-1A and NIW immigration applicants. This article covers the technical decisions, trade-offs, and lessons learned during the process.

The Problem

When I started researching immigration costs, I found that most information was scattered across forum posts, attorney websites with outdated fee schedules, and Reddit threads with conflicting numbers. USCIS publishes its filing fees, but the total cost involves many additional components that vary by situation.

The goal was straightforward: build a calculator that gives applicants a realistic cost breakdown based on their specific circumstances, without requiring them to create an account or pay for the information.

Architecture Decisions

Why Static Calculations Over AI

The first major decision was whether to use AI/ML for cost estimation or stick with deterministic calculations. We chose deterministic logic for several reasons:

• Transparency: Users can see exactly how each number is derived
• Auditability: Immigration costs involve specific, known fees from USCIS
• Trust: When money is involved, people want predictable, explainable outputs
• Maintenance: Fee schedules change on known dates; updating a lookup table is simpler than retraining a model

The calculator uses a structured fee database that maps visa categories to their component costs:

interface CostComponent {
  category: "filing" | "biometrics" | "medical" | "legal" | "translation" | "other";
  name: string;
  amount: number;
  required: boolean;
  notes?: string;
  lastUpdated: string;
}

interface VisaCostProfile {
  visaType: "EB1A" | "NIW" | "EB2" | "EB3";
  components: CostComponent[];
  premiumProcessingFee?: number;
}

Handling Fee Variability

Some costs are fixed (USCIS filing fees), while others vary widely (attorney fees, translation costs). For variable costs, I implemented range-based estimation:

interface VariableCost {
  min: number;
  max: number;
  median: number;
  source: string;
  confidence: "high" | "medium" | "low";
}

Attorney fees, for example, range from $3,000 for basic NIW petitions to $15,000+ for complex EB-1A cases. Rather than picking a single number, the calculator shows the range and lets users adjust based on their situation.

Client-Side vs Server-Side

All calculations run client-side. This was a deliberate choice:

• Privacy: No immigration-related data leaves the browser
• Speed: Instant results without network round-trips
• Cost: Zero server compute costs for calculations
• Offline capability: Works without internet after initial load

The only server interaction is loading the fee database, which is cached aggressively since fees change infrequently.

Technical Implementation

Next.js with TypeScript

The project uses Next.js with TypeScript for type safety across the cost calculation logic. This matters because immigration fees have complex interdependencies. For example, the I-140 filing fee differs based on employer size, and premium processing availability depends on the visa category.

TypeScript catches cases where these relationships might be incorrectly modeled:

function calculateTotalCost(
  visaType: VisaType,
  options: CalculatorOptions
): CostBreakdown {
  const baseFees = getBaseFees(visaType);
  const optionalFees = options.premiumProcessing
    ? baseFees.premiumProcessingFee ?? 0
    : 0;
  const legalFees = estimateLegalFees(visaType, options.complexity);

  return {
    filing: baseFees.totalFiling,
    legal: legalFees,
    medical: MEDICAL_EXAM_FEE,
    premium: optionalFees,
    total: baseFees.totalFiling + legalFees.median + MEDICAL_EXAM_FEE + optionalFees,
    range: {
      min: baseFees.totalFiling + legalFees.min + MEDICAL_EXAM_FEE,
      max: baseFees.totalFiling + legalFees.max + MEDICAL_EXAM_FEE + optionalFees
    }
  };
}

Keeping Fee Data Current

USCIS updates fees periodically (the last major update was in April 2024). The fee database is structured as a versioned JSON file with effective dates:

{
  "version": "2024-04",
  "effectiveDate": "2024-04-01",
  "fees": {
    "I-140": {
      "standard": 700,
      "smallEntity": 350,
      "premiumProcessing": 2805
    }
  }
}

A scheduled check compares the current fee version against the USCIS fee schedule page and flags discrepancies for manual review.

Design Trade-offs

Simplicity vs Completeness

Immigration cost estimation has a long tail of edge cases: dependents filing I-485 concurrently, consular processing vs adjustment of status, expedited processing for medical reasons, fee waivers for certain categories.

We chose to handle the 80% case well rather than the 100% case poorly. The calculator covers the primary applicant pathway for EB-1A and NIW, with clear notes about additional costs for dependents and edge cases.

Accuracy vs Liability

Displaying specific dollar amounts creates an implicit accuracy promise. Every number in the calculator includes its source and last-verified date. The UI clearly states that estimates are for planning purposes and that USCIS fees should be verified at the time of filing.

You can try this free calculator to see how these design decisions play out in practice.

Free vs Gated

We considered requiring email registration to access detailed breakdowns. The argument for gating: collect leads for future features. The argument against: immigration applicants are already dealing with enough bureaucratic friction.

We went with fully free, no-registration access. The hypothesis is that removing friction builds trust, which leads to organic sharing among immigrant communities where word-of-mouth is the primary distribution channel.

Lessons Learned

1. YMYL Content Requires Extra Care

Google classifies immigration content as "Your Money or Your Life" (YMYL), meaning it applies higher quality standards. Every claim in the calculator needs a verifiable source. Vague cost ranges without citations would hurt both SEO and user trust.

2. Internationalization Matters

Immigration applicants come from everywhere. The calculator needed to handle currency display (showing USD clearly), date formats, and clear English that non-native speakers can understand. We avoided idioms and used straightforward language throughout.

3. Mobile-First Is Non-Negotiable

Over 60% of traffic to immigration-related content comes from mobile devices. The calculator UI was designed for thumbs first, mice second. Input fields use appropriate mobile keyboards (numeric for dollar amounts), and the results layout works on narrow screens.

4. Data Freshness Is a Feature

Showing when fee data was last verified turned out to be a significant trust signal. Users explicitly told us they appreciated knowing the data was current, not pulled from a 2019 blog post.

What I Would Do Differently

If starting over, I would:

• Add comparison views earlier: Users frequently want to compare EB-1A vs NIW costs side-by-side
• Build in a timeline estimator: Cost is one variable; time is the other major concern
• Create an API: Other immigration tools could integrate cost data rather than maintaining their own databases

Pairing the cost calculator with the assessment tool that evaluates qualification criteria gives applicants a more complete picture: not just whether they can afford to apply, but whether they should.

Conclusion

Building tools for immigration applicants comes with unique technical and ethical considerations. The cost calculator prioritizes transparency, privacy, and accuracy over engagement metrics. Every technical decision was filtered through the question: does this serve someone making a high-stakes financial decision about their future?

The full stack is Next.js, TypeScript, and Tailwind CSS, deployed on Vercel. No database, no user accounts, no tracking beyond basic analytics. Sometimes the best architecture is the simplest one that serves the user well.