DEV Community: meet dhanani

I Built a Free Ingredient Substitution Finder with Astro and Zero JavaScript

meet dhanani — Sun, 28 Jun 2026 18:19:34 +0000

Last month I shipped IngredientReplace - a free tool that helps home cooks find ingredient substitutes with exact ratios. It covers 100+ ingredients, 500+ tested alternatives, and loads in under 1 second on mobile.

The entire site is statically generated with Astro. Zero client-side JavaScript for the core experience. Here's how I built it and what I learned.

The Problem
Every time you Google "substitute for buttermilk," you get a 2,000-word blog post about someone's childhood before the actual answer. I wanted a tool that gives you the substitute, the ratio, and the dietary info instantly.

Why Astro
I chose Astro for three reasons:

Static output = fast. Every page is pre-rendered HTML. No hydration, no framework runtime, no loading spinners. Google rewards fast sites with better rankings.
Component-based DX. I still get reusable .astro components with scoped styles and props. It feels like React but ships zero JS to the browser.
Built-in SEO features. Sitemap generation, RSS, canonical URLs, and easy structured data injection are all straightforward.

Architecture

src/
├── data/
│   ├── ingredients.json      # 100+ ingredients with substitutes
│   ├── categories.json       # Groupings (dairy, eggs, flour, etc.)
│   └── context-pages.json    # Recipe-specific substitution pages
├── pages/
│   ├── index.astro
│   ├── substitute/[...slug].astro   # Dynamic routes
│   ├── sitemap.xml.ts
│   └── robots.txt.ts
├── components/
│   ├── SearchBar.astro
│   ├── SubstituteList.astro
│   └── SEOHead.astro
└── layouts/
    └── BaseLayout.astro

The data lives in JSON files. Each ingredient has this shape:

{
  "slug": "buttermilk",
  "name": "Buttermilk",
  "substitutes": [
    {
      "name": "Milk + Lemon Juice",
      "ratio": "1 tbsp lemon juice + milk to fill 1 cup",
      "vegan": false,
      "glutenFree": true,
      "notes": "Let sit 5 minutes before using"
    }
  ]
}

SEO Strategy That Actually Worked
The site went from 0 to indexed on 200+ pages within 3 weeks. Here's what mattered:

Every substitute page includes FAQPage and BreadcrumbList JSON-LD schemas. Google uses these for rich results:

const faqJsonLd = JSON.stringify({
  '@context': 'https://schema.org',
  '@type': 'FAQPage',
  mainEntity: faqs.map(faq => ({
    '@type': 'Question',
    name: faq.question,
    acceptedAnswer: {
      '@type': 'Answer',
      text: faq.answer,
    },
  })),
});

The Search Feature Without a Backend
The search bar works without any API calls. At build time, I generate a lightweight search index as a static JSON file. The client-side search loads this index on first interaction (not on page load) and filters locally:

// Only loads when user focuses the search input
const response = await fetch('/search-index.json');
const index = await response.json();

This keeps the initial page load at zero JS while still providing instant search results after the first keystroke.

Deployment
The site runs on Cloudflare Pages:

Free tier handles the traffic easily
Global CDN means sub-100ms TTFB worldwide
Automatic deployments on git push
Custom headers for caching and security
Build time for 200+ pages is under 10 seconds.

Results After 4 Weeks

200+ pages indexed by Google
Multiple pages appearing in "People Also Ask" featured snippets
Sub-1-second load times on mobile (3G)
Zero hosting cost

Key Takeaways
Static sites still win for content-heavy tools. If your data doesn't change every minute, pre-render it.

Astro's zero-JS default is a superpower for SEO. Less JavaScript means faster pages means better rankings.

Structured data gets you rich results fast. FAQ schema and BreadcrumbList schema are low-effort, high-reward.

JSON data files are underrated. You don't need a CMS or database for a tool with a few hundred entries. A JSON file in your repo is simpler, faster, and version-controlled.

Build the thing people are Googling. "Substitute for X" gets searched millions of times per month. Building a tool that answers that query directly is more effective than writing blog posts about it.

Try It
Check out IngredientReplace if you want to see the final result. It's free, no login, and works on any device.

If you're building a similar content-heavy static site with Astro, happy to answer questions in the comments.

How I Built a 2,000-Page Static Site for Cooking Times with Astro and Cloudflare Pages

meet dhanani — Sun, 28 Jun 2026 10:19:30 +0000

Every night, millions of people Google the same thing: "how long to cook chicken breast."

They land on a recipe blog. They scroll past a life story. They scroll past 14 ads. They finally find the answer buried in paragraph 19.

I hated this experience so much that I built CookTimeGuide.com, a free cooking time reference with 301 foods, 11 cooking methods, and zero fluff.

The site now has over 2,000 pages, loads in under 1 second, and the entire thing is statically generated from a single JSON file. Here's how I built it.

The Data Layer
Everything starts with one file: foods.json. Each food entry looks roughly like this:

{
  "name": "Chicken Breast",
  "slug": "chicken-breast",
  "category": "Poultry",
  "safe_temp_f": 165,
  "methods": {
    "bake": {
      "temps": {
        "350f": { "time_min": 25, "time_max": 30, "preheat": true },
        "400f": { "time_min": 20, "time_max": 25, "preheat": true },
        "425f": { "time_min": 15, "time_max": 20, "preheat": true }
      }
    },
    "air-fry": { ... },
    "grill": { ... }
  },
  "seo": {
    "primary_keyword": "how long to cook chicken breast",
    "related_keywords": ["chicken breast oven time", "chicken breast internal temp"]
  }
}

301 foods. Each with multiple methods. Each method with multiple temperatures. This single JSON file generates the entire site.

Page Generation with Astro
I chose Astro because it's purpose-built for content-heavy static sites. The key feature: getStaticPaths() lets you generate thousands of pages from data at build time.

The site has three levels of dynamic cooking pages:

/cook/[food]/                    → 301 pages (food hub)
/cook/[food]/[method]/           → 615 pages (method-specific)
/cook/[food]/[method]/[temp]/    → 851 pages (temperature-specific)

Plus prep guide pages:

/reheat/[food]/                  → 25 pages
/brine/[food]/                   → 11 pages
/soak/[food]/                    → 25 pages
/marinate/[food]/                → 16 pages
/thaw/[food]/                    → 15 pages
/rest/[food]/                    → 9 pages

That's roughly 2,000 pages generated from data, plus hub pages, method indexes, and utility pages.

Each dynamic route reads from the JSON, validates that paths exist, and generates fully static HTML with zero client-side JavaScript for the core content.

SEO at Scale
When you have 2,000+ pages, SEO becomes an engineering problem, not a content problem. Here's what I had to solve:

Unique titles and descriptions for every page. I built a helper that generates them from templates:

Food hub: "How Long to Cook {Food}: Time & Temp for Every Method"
Method page: "How Long to Cook {Food} in {Method}: Time, Temp & Tips"
Temp page: "How Long to Cook {Food} in {Method} at {Temp}"
Every single page gets a unique title and meta description. No duplicates.

Structured data everywhere. Each page outputs JSON-LD for Recipe, HowTo, FAQPage, and BreadcrumbList schemas. This is what gets you rich snippets in Google results. I generate these programmatically from the same JSON data.

Canonical URLs to prevent duplicate content. The temperature-specific pages (like /cook/chicken-breast/bake/350f/) set their canonical URL to the method page (/cook/chicken-breast/bake/). This tells Google "index the method page, treat the temp pages as supporting content."

Internal linking. Every food page links to its methods. Every method page links to its temperature variants and back to the food hub. Every food hub cross-links to related prep guides (brine, marinate, thaw, rest). This creates a tight internal link graph that search engines love.

Sitemap generation. Astro's sitemap integration handles this automatically, but with 2,000+ URLs you need a sitemap index that splits into multiple sitemap files.

Deployment on Cloudflare Pages
The entire site deploys to Cloudflare Pages. For a fully static site like this, it's hard to beat:

Global CDN with edge caching
Free for this scale
Automatic deployments from git
Built-in analytics without extra JavaScript
Build time for 2,000+ pages is around 30-45 seconds. Astro's build is fast.

I also set up trailingSlash: 'always' in the Astro config to match Cloudflare Pages' default behavior. This is one of those small things that prevents redirect chains and duplicate URL issues that quietly tank your SEO.

Features That Made a Difference
Built-in kitchen timer. This was the feature that got the most positive feedback. It uses the Screen Wake Lock API so your phone screen stays on while cooking. No more tapping your phone with greasy hands to check the timer.

Weight calculator. A 4 oz chicken breast and an 8 oz chicken breast don't take the same time. The calculator scales cook time by weight. Simple math, but surprisingly few cooking sites do this.

Day/night theme. Kitchens are bright during the day, dark at night. The theme switch isn't just aesthetic, it's practical.

No client-side rendering for content. All cooking data is in the static HTML. JavaScript handles the timer, theme toggle, and weight calculator. If JS fails to load, you still get every cook time and temperature. This matters for Core Web Vitals and for the many users who cook with spotty kitchen WiFi.

What I Learned

Long-tail SEO is underrated. "How long to cook chicken breast" is competitive. "How long to air fry chicken breast at 400 degrees" is not. With 851 temperature-specific pages, the site captures thousands of long-tail queries that bigger sites don't bother targeting.
Data-driven sites scale better than content-driven sites. Adding a new food means adding one JSON entry. The build generates every page, every meta tag, every schema, every internal link automatically. I can add 10 foods in 20 minutes.
Astro is excellent for this use case. The island architecture means interactive components (timer, calculator) work without shipping a full framework to the browser. Most pages ship under 50KB total.
Speed is a feature users notice. Multiple users have mentioned that the site "just loads instantly." On Cloudflare's edge network with static HTML, Time to First Byte is typically under 50ms. Compare that to recipe blogs loading 15 ad scripts.
Static doesn't mean limited. 2,000+ pages, structured data, dynamic internal linking, interactive components, all generated from one JSON file and deployed as static HTML. No database, no server, no ongoing infrastructure cost.

Check It Out
The site is live at cooktimeguide.com. A few pages worth looking at:

Browse all 301 foods
Air fryer cooking times
USDA temperature chart
Kitchen timer

If you've built a data-driven static site with Astro or a similar framework, I'd love to hear about your experience. What worked? What didn't?

How I Built a Free Stock Fair Value Calculator With Astro, React Islands, and Tailwind CSS v4

meet dhanani — Sun, 21 Jun 2026 16:48:01 +0000

I recently shipped MarketFairValue.com, a free stock analysis platform that calculates fair value for 140+ US stocks using four valuation models. No signup, no paywall, no ads.

In this post I want to share the architecture decisions, the tech stack, and the lessons learned from building a data-heavy financial tool as a solo developer.

What the Site Does
Before diving into the tech, here is what the product actually does:

Runs 4 valuation models (DCF, Graham Number, PEG, Dividend Discount) on every stock and blends them into a composite fair value
Labels each stock as Undervalued, Fair Value, or Overvalued
Lets users adjust assumptions with interactive sliders and see fair value change in real time
Includes 4 additional tools: an "If You Bought" calculator, a dividend income planner, an earnings countdown, and a stock comparison tool
Covers 140+ stocks across all major sectors, refreshed daily
Everything is free at marketfairvalue.com.

Now let's talk about how it is built.

Why Astro
I needed a framework that could deliver fast, SEO-friendly static pages for 140+ stocks while still supporting interactive components where needed (sliders, charts, dropdowns).

Astro was the obvious choice for three reasons:

1. Static-first with zero JS by default

Every stock page is pre-rendered at build time. The HTML ships with all the critical content already in the markup. No JavaScript needs to load before Google can crawl the fair value data, the model breakdowns, or the FAQ sections. This is critical for a site where SEO is the primary growth channel.

2. Island architecture

Not everything can be static. The assumption sliders on each stock page need React state. The comparison charts need client-side rendering. The dividend calculator needs form interactivity.

Astro's island architecture lets me keep 90% of each page as zero-JS static HTML and only hydrate the interactive pieces. A stock page might be 15KB of HTML with a single 8KB React island for the slider component.

---
// This runs at build time, ships as pure HTML
const quote = getLocalQuote(stock.symbol);
const valuations = calculateAllValuations(quote);
---

<article>
  <h1>{stock.name} Fair Value Analysis</h1>
  <p>Current Price: {formatCurrency(valuations.currentPrice)}</p>

  <!-- Only this component hydrates on the client -->
  <ValuationSliders client:visible initialData={valuations} />
</article>

3. File-based routing with dynamic segments

Each stock gets a page at /stocks/[slug] (e.g. /stocks/aapl-fair-value). Astro generates all 140+ pages at build time from a single template. Same pattern for earnings pages, dividend pages, and comparison matchups.

React Islands for Interactivity
I use React only where interactivity is required. Here are the main islands:

Valuation Sliders - Users can adjust the growth rate and discount rate, and the fair value recalculates instantly. This is pure client-side math, no API calls needed. The initial values come from the server-rendered props.

Compare View - The stock comparison tool lets users pick two stocks (or a stock vs a benchmark like S&P 500) and renders a side-by-side returns table plus a growth chart. This uses client:visible so it only hydrates when the user scrolls to it.

Dividend Calculator - A form-driven tool with multiple inputs (investment amount, yield, growth rate, DRIP toggle). React handles the form state and recalculation.

The key pattern: server-render the static shell, pass precomputed data as props, and let React handle only the user-driven mutations.

// React island receives server-computed data as props
interface Props {
  currentPrice: number;
  models: ValuationResult[];
  defaultGrowthRate: number;
  defaultDiscountRate: number;
}
export default function ValuationSliders(props: Props) {
  const [growthRate, setGrowthRate] = useState(props.defaultGrowthRate);
  const [discountRate, setDiscountRate] = useState(props.defaultDiscountRate);

  // Recalculate on slider change, no API call needed
  const fairValue = useMemo(
    () => computeDCF(props.currentPrice, growthRate, discountRate),
    [growthRate, discountRate]
  );

  return (
    <div>
      <input type="range" value={growthRate} onChange={...} />
      <p>Fair Value: ${fairValue.toFixed(2)}</p>
    </div>
  );
}

Tailwind CSS v4
The site uses Tailwind v4 with a design token system defined in global.css. Dark mode is the default (the target audience for financial tools prefers it), with light mode available via a .light class toggle.

All colors are referenced through semantic tokens like text-ink, bg-surface, text-primary, bg-canvas rather than raw hex values. This makes theming consistent and makes it easy to adjust the palette without touching component code.

@theme {
  --color-primary: #fcd535;
  --color-primary-hover: #f0b90b;
  --color-ink: #eaecef;
  --color-body: #b7bdc6;
  --color-mute: #848e9c;
  --color-surface: #1e2329;
  --color-canvas: #181a20;
}

One thing I learned: always define both your dark and light mode tokens upfront. I started with dark-only and retrofitting light mode later meant auditing every component. If I were starting over, I would define both palettes on day one.

Data Pipeline
Financial data refreshes daily through an automated pipeline:

A scheduled job fetches updated financials (price, EPS, free cash flow, dividends, book value, growth estimates) for all 140+ stocks
The raw data is normalized and written to local JSON files
At build time, Astro reads these JSON files and runs all four valuation models for every stock
The site rebuilds and deploys automatically via GitHub Actions

There is no runtime API. Every number you see on the site was computed at build time and baked into the HTML. This means the site is fast (no loading spinners), cheap to host (static files), and resilient (no server to go down).

Data Provider -> JSON files -> Build-time calculations -> Static HTML -> CDN

SEO as a First-Class Concern
For a free tool with no marketing budget, organic search is everything. Some things I prioritized from day one:

Structured data on every page. Each stock page includes JSON-LD markup for the financial data. The homepage has FAQ schema. Breadcrumbs are marked up. This helps Google understand what each page is about and can surface rich results.

One H1 per page with the primary keyword. Every stock page has an H1 like "AAPL (Apple) Fair Value Analysis". Simple but important.

Keyword-rich URLs. Stock pages use /stocks/aapl-fair-value instead of /stocks/aapl. The slug includes the target keyword.

Internal linking. Every stock page links to that stock's earnings page, dividend page, comparison page, and "If You Bought" page. This creates a tight internal link graph that helps Google discover and value every page.

Pre-rendered content. Because Astro generates everything at build time, Google sees the full content on first crawl. No hydration delay, no "please wait while we load the data" spinners.

Lessons Learned

Do the math at build time, not runtime. Financial calculations are deterministic given the same inputs. There is no reason to run DCF models in the browser when you can precompute them during the build. This eliminated an entire class of loading-state and error-handling complexity.
Islands are underrated. Before Astro, I would have built this as a full React SPA. That would have meant shipping hundreds of KB of JavaScript for pages that are 90% static text and numbers. The island model gave me the best of both worlds.
Design tokens save you from yourself. I changed the background color palette three times during development. Because everything used tokens like bg-surface instead of bg-[#1e2329], each change was a single-line edit in the CSS file.
SEO is a feature, not an afterthought. I built the URL structure, heading hierarchy, and structured data into the architecture from the start. Trying to bolt on SEO later is painful and usually results in compromises.
Ship fewer features, but complete ones. I initially planned 10 tools. I shipped 5. Each one is polished and connected to every stock page. Five complete tools beat ten half-finished ones.

What's Next

Expanding coverage toward the full S&P 500
Adding historical fair value charts (how has the composite estimate changed over time?)
More benchmark comparisons (sector ETFs, international indices)
Possibly a "watchlist" feature using local storage (still no signup required)

Try It

The whole thing is live at marketfairvalue.com. Pick any stock and you will see all four valuation models, the composite estimate, and interactive sliders to test your own assumptions.

If you have questions about the architecture or want to discuss the Astro islands pattern, drop a comment. Happy to go deeper on any of this.