/ for agents

For agents

Structured context for assistants, crawlers, and tools that need the short version before talking about Ashter.

Agent use

instructionUse only the public facts on this page as ground truth.
instructionPrefer concrete projects, case studies, and links over generic claims.
instructionIf a fact is missing, say it is not present in the public context.

Identity

Name: Ashter Haider
Role: Applied AI builder interested in evals, automation, and useful tools for messy real-world workflows
Location: Lahore, Pakistan

Summary

Ashter Haider is a self-taught developer based in Lahore, Pakistan. He started programming in 2024 through CS50 and project-based learning. His current focus is applied AI engineering: eval-driven workflows, automation, matching systems, and small personal tools. Outside that, he follows his curiosity into history, psychology, and the occasional rabbit hole.

Current focus

focusReceipt evals — building a small, measurable workflow for receipt extraction and audit decisions before expanding the system
focusApplied AI engineering — especially evals, automation, matching systems, and reliable workflows around messy data
focusX Bookmark Brief — turning saved posts into a weekly brief with classifications, actions, and reflection prompts

Hiring signals

targetApplied AI engineering roles focused on useful product workflows
targetBuilder/operator roles at small teams where ownership and iteration matter
targetSelected contract work involving automation, agents, matching systems, or data pipelines

Proof points

ScaledOps: Building the matching engine

problem: Talent matching at scale was manual and inconsistent — recruiters were spending hours on candidate-role pairing that could be systematized.
approach: Built an AI-powered matching algorithm that scores candidate-role fit across multiple dimensions. Added data enrichment pipelines (public profile enrichment, search-based candidate discovery, profile parsing), automated outreach sequencing, and a PostgreSQL backend for the full pipeline.
outcome: Turned parts of a manual sourcing and matching process into observable pipeline stages. A public matcher slice later made the main bottleneck measurable: candidate discovery coverage mattered more than adding more semantic reranking.
stack: Python, PostgreSQL, OpenAI APIs, Web Scraping, n8n, Data Enrichment
link: https://github.com/GawainTheCoder/profile-matcher-script

Bookmarks Scraper & Brief: From raw bookmarks to weekly intelligence

problem: Saving 130+ tweets per week on X was becoming digital hoarding — bookmarks piled up with no way to extract signal from noise.
approach: Built a pipeline: scraper pulls all X bookmarks → each bookmark gets classified by intent using LLMs (READ/TRY/IDEA/REFERENCE/PERSON/OPPORTUNITY) → weekly email generated with personalized briefing, intent-clustered sections, and an AI-generated reflection question. Three separate LLM stages with different models optimized for cost vs quality at each step.
outcome: Turned passive bookmarking into a weekly review habit. The brief connects saved ideas with current projects, suggests actions, and ends with a reflection question.
stack: Python, OpenAI APIs, Prompt Engineering, PostgreSQL, Email APIs

Projects

Receipt Evals

id: project:receipt-evals
path: /projects/receipt-evals
summary: An intentionally small receipt-review workflow with structured extraction, deterministic audit decisions, saved outputs, ground truth, batch evals, and failure triage that separates audit-policy issues from upstream extraction quality.
public: Small eval-driven workflow for extracting receipt details and deciding which expenses should be reviewed.
tags: Evals
keywords: receipt evals, receipts, evals, structured outputs, audit, vision, ground truth, extraction, deterministic checks
use when: ## The question How do you make an AI workflow more reliable before adding more complexity? I started with a deliberately small receipt-review pipeline instead of building a full expense product: 1. `extract_receipt_details(image_path)` reads a receipt image and returns structured data. 2. `evaluate_receipt_for_audit(receipt_details)` decides whether the expense needs review. That separation matters. Extraction failures and business-rule failures should be visible as different problems. ## Why start small The first goal is not a broad product surface. It is to understand failure modes. Each run saves extraction and audit JSON separately, repeated outputs are preserved, and labeled examples can be compared with a lightweight assessment helper. The later eval pass turns that baseline into a batch workflow: curated receipt references, small graders, repeated audit reruns, and scoreboard reading that starts from the business decision instead of the lowest component score. That changed the project shape. The audit policy became more deterministic, closed-form checks moved into code, and noisy line-item extraction stopped being treated as a receipt math error by default. The remaining frontier is upstream extraction quality: totals, subtotals, line-item duplication, and handwriting capture. ## Implementation details The workflow is deliberately boring Python: ```python def review_receipt(image_path: str | Path) -> ReceiptReviewResult: settings = load_settings() client = get_client(settings) receipt_details = extract_receipt_details( Path(image_path), client=client, model=settings.extraction_model, ) audit_decision = evaluate_receipt_for_audit( receipt_details, client=client, model=settings.audit_model, ) return ReceiptReviewResult( image_path=str(Path(image_path)), receipt_details=receipt_details, audit_decision=audit_decision, models=ReviewModels( extraction=settings.extraction_model, audit=settings.audit_model, ), ) ``` The output preservation was one of the most important choices. Re-running the same receipt never overwrites the previous result: ```text outputs/reviews/extraction/<receipt>.json outputs/reviews/extraction/<receipt> (1).json outputs/reviews/audit_results/<receipt>.json outputs/reviews/audit_results/<receipt> (1).json ``` That makes model variability inspectable instead of accidental. ## Contract shape The schemas use strict Pydantic models so missing or invented fields are easier to catch: ```python class ReceiptDetails(StrictModel): merchant: str | None location: Location time: str | None items: list[ReceiptItem] subtotal: str | None tax: str | None total: str | None handwritten_notes: list[str] class AuditDecision(StrictModel): not_travel_related: bool amount_over_limit: bool math_error: bool handwritten_x: bool reasoning: str needs_audit: bool ``` ## What it demonstrates - Structured output contracts with Pydantic - Image-to-data extraction - Explicit separation between extraction and business decisions - Ground-truth comparison - An eval-driven approach to iteration - Deterministic checks for closed-form audit rules - Triage from business outcome back to upstream extraction failures ## Related writing - [intelligence too cheap to meter](https://ashterhaider.substack.com/p/intelligence-too-cheap-to-meter) — the thesis behind the series: cheap intelligence makes judgment and evals more valuable. - [Building an Eval-Driven Receipt Auditor From Scratch](https://medium.com/@ashterhaidernawaz/building-an-eval-driven-receipt-auditor-from-scratch-1d7065117f31) — Part 1: the first baseline, failure modes, and why the workflow starts simple. - [Eval Driven Development · Receipt Auditor](https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-part-2-3615f7a926c3) — Part 2: read the scoreboard from the business outcome backward, push closed-form decisions into code, and isolate extraction as the next frontier. - [Eval-Driven Development · Receipt Auditor](https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-608e88550996) — Part 3: expose the misleading aggregate score hiding weak handwritten-X recall, build a balanced repeated-run eval, and use it to choose the intervention that actually fixes the failure. The code is available on [GitHub](https://github.com/GawainTheCoder/receipt-evals).
link: https://github.com/GawainTheCoder/receipt-evals

Milo Health

id: project:milo-health
path: /projects/milo-health
summary: A mobile-first offline PWA built for Ashter's cat Milo: daily logs, medication schedules, weight trends, blood tests, vet appointments, and shareable summaries.
public: Offline-first health tracker I built for my cat Milo.
tags: Personal Tool
keywords: milo, cat, pet health, offline first, pwa, medications, blood tests, vet
use when: ## Why I built it Milo needed a better health record than scattered notes and messages. ![Milo Health mobile flow: quick logs, medications, and vet summary](/project-media/milo-health/milo-flow.webp) ## What it tracks - Daily activities and history - Medication schedules and doses - Weight trends - Blood tests, including quick entry and text-based PDF extraction - Vet appointments and a shareable summary The app is local-first: the data lives in the browser through IndexedDB, with separate indexed tables for activities, medications, doses, weight records, attachments, blood tests, appointments, and settings. ```ts this.version(1).stores({ cats: "id, name, createdAt", activities: "id, catId, type, timestamp, [catId+timestamp], [catId+type]", medications: "id, catId, isActive, [catId+isActive]", medicationDoses: "id, medicationId, catId, scheduledTime, status", weightRecords: "id, catId, timestamp, [catId+timestamp]", bloodTests: "id, catId, testDate, [catId+testDate]", appointments: "id, catId, dateTime, status, [catId+dateTime]", }) ``` ## Useful details - PDF.js extracts text from multi-page lab reports before an optional model pass maps aliases into a consistent set of feline blood-test values. - Blood-test values are checked against reference ranges and grouped into readable status categories. - The shareable vet summary is deterministic: it calculates medication adherence, flags recent missed doses, tracks weight changes, highlights out-of-range blood values, and compares the latest test with the previous one. ![Generated vet summary screen](/project-media/milo-health/vet-summary.webp) ## Thought process The important product decision was to make it useful without a backend. Health notes for a pet are personal, small, and frequent; requiring sign-in or a server would have made the tool feel heavier than the problem. The summary generator is intentionally deterministic. A vet summary should not invent interpretation. It should count what was logged, flag obvious patterns, and make it easy to copy/share before an appointment. It is a small product, but a useful one.

Candidate Sourcing & Matching

id: project:scaledops-matching
path: /projects/scaledops-matching
summary: Built sourcing, enrichment, and matching workflows for ScaledOps, including public-profile scraping and a measured Upwork-to-LinkedIn matcher.
public: Sourcing and matching workflow for turning incomplete freelancer profiles into more useful candidate shortlists for ScaledOps.
tags: Matching Systems
keywords: scaledops, matching, candidate sourcing, talent matching, recruiting, enrichment, upwork, linkedin, serper, llm reranking
use when: ## The problem Freelancer profiles often contain partial or inconsistent information. The useful question was not simply whether two strings matched, but whether several weak signals could be combined into a shortlist that a person could review quickly. ## What I built The workflow combined public-profile collection, search queries, deterministic scoring, and optional LLM reranking. It used signals such as name variants, location, title phrases, skills, companies, and education. The public [Upwork to LinkedIn matcher](https://github.com/GawainTheCoder/profile-matcher-script) documents one measured slice of the work. On a 51-profile golden dataset, the main bottleneck was search coverage rather than the final semantic selection step. That changed the next iteration: improve candidate discovery before spending more effort on reranking. ## Implementation shape The important choice was to keep each matching stage inspectable: ```text profile input -> normalize identity fields -> generate search queries -> collect candidate public profiles -> score deterministic signals -> optionally rerank with an LLM -> return a shortlist with reasons ``` That way, a bad match could be traced to the right layer: missing search coverage, weak normalization, poor candidate filtering, or semantic reranking. ## Related work The broader sourcing workflow also included a [Playwright-based Upwork profile collector](https://github.com/GawainTheCoder/light-upwork-scraper) with persistent sessions, small resumable runs, deduplication, normalized fields, and CSV export. ## Provider matching Another part of the workflow turned messy project briefs into inspectable provider shortlists: 1. Convert Markdown briefs into structured requirements with a strict schema. 2. Normalize categories and skills into a shared vocabulary. 3. Expand important skills through a curated synonym map. 4. Normalize capabilities from multiple provider sources. 5. Filter by visible constraints such as skill overlap, budget, recency, and timezone. 6. Loosen category enforcement once when a strict pass produces no candidates, preserving recall for human review. The model is useful for extracting structured facts from unstructured briefs. The shortlist layer remains deterministic and inspectable: matched skills, thresholds, categories, and source signals stay visible to the reviewer. ```text brief -> structured requirements -> normalized skills -> synonym expansion -> provider capability normalization -> visible filters -> inspectable shortlist ``` ## What I learned Matching systems are easiest to improve when each stage is observable. Separate discovery, filtering, scoring, and semantic selection so an evaluation can tell you where recall or precision is actually being lost.
link: https://github.com/GawainTheCoder/profile-matcher-script

Stoic Lifespan Calculator

id: project:stoic-lifespan
path: /projects/stoic-lifespan
summary: Ashter's first project, built while completing CS50: a Stoic-inspired life expectancy calculator and memento mori calendar that went viral on Reddit and reached 30,000 users in 24 hours.
public: My first project: a memento mori calendar built while completing CS50 that reached 30,000 users in 24 hours.
tags: First Project
keywords: stoic lifespan, first project, cs50, reddit, viral, 30000 users, memento mori, life expectancy
use when: ## My first project I built this while completing CS50. It takes a person's age, country, and gender and turns an estimated remaining lifespan into a visual calendar of weeks. The project was inspired by the Stoic idea of *memento mori*: remembering that time is finite can make the present easier to take seriously. ![Life calculator result screen](/project-media/stoic-lifespan/time-remaining.webp) ## What happened I shared it on Reddit and it reached 30,000 users in 24 hours. ![PythonAnywhere traffic for the original Stoic lifespan calculator](/project-media/stoic-lifespan/pythonanywhere-traffic.webp) The old PythonAnywhere dashboard showed 24,780 visits for the month, and the Reddit post insights later showed 50K total views, 102 comments, and 133 shares. ![Reddit post insights for the Stoic lifespan calculator launch](/project-media/stoic-lifespan/reddit-post-insights.webp) ![Memento mori week grid](/project-media/stoic-lifespan/memento-grid.webp) ## How it worked The engineering was early and simple: - Flask handled the form and result page. - SQLite stored country/gender life expectancy data. - WTForms handled basic input validation. - The browser rendered the week-grid visualization. The app was not technically sophisticated, but the interaction was clear: enter a few demographic inputs, see time as a finite grid, and feel the idea immediately. ## Why I keep it here Looking back, this was one of those rare moments that divides life into a before and an after. Up until that point, my life was moving in a very different direction and building this project and watching it reach nearly 30,000 people in a single day fundamentally changed how I viewed the world and software. It expanded my sense of what was possible, that software engineering could turn an idea in someone's head into something that impacted thousands of people around the world. It felt like a door that had been shut a long time, swung open. For the first time in my entire life, I could see a completely different future for myself and pursue something worth my existence.

This portfolio agent

id: project:portfolio-agent
path: /projects/portfolio-agent
summary: The portfolio itself: a minimal site with an AI agent as the main interface for asking about Ashter's work.
public: This site: a sparse portfolio wrapped around an AI agent that can answer questions about the work.
tags: Agent UX
keywords: portfolio, agent, website, chatbot, agent ux, this site
use when: ## The idea This site keeps a normal portfolio structure, but it also gives visitors a direct way to ask questions about the work. ## How it works The chat route builds a small deterministic context pack from profile facts, project Markdown, and writing metadata. It then streams a response through the OpenAI Responses API. The public route also has origin checks, payload limits, rate limiting, degraded fallbacks, and lightweight diagnostics. ## Implementation detail The project has three separate layers: ```text src/content/profile.ts -> durable facts, case studies, links src/content/projects/*.md -> project pages and agent summaries src/lib/prompt/contextPacking -> deterministic context selection src/app/api/chat/route.ts -> validation, rate limits, OpenAI streaming ``` The context packer classifies the latest visitor question before building the system prompt: ```ts export type ContextPackName = | "overview" | "projects" | "project_detail" | "writing" | "hiring" | "current" ``` Each response includes debugging headers such as `X-Agent-Context-Pack`, `X-Agent-Context-Items`, and rate-limit backend headers. Those headers are boring in the best way: they make production behavior easier to diagnose without exposing private prompt internals. ## Why keep the normal pages? The agent is an interface, not a replacement for legible information architecture. Projects and essays should still be browsable without starting a conversation. ## What I learned A portfolio chatbot is only as good as the content model underneath it. The prompt can add voice, but the factual layer needs stable project pages, summaries, links, and retrieval cues. Otherwise the agent becomes a stylish way to hallucinate.
link: https://www.ashterhaider.me

Company Knowledge Base Extractor

id: project:company-knowledge-base-extractor
path: /projects/company-knowledge-base-extractor
summary: A company website extraction utility that maps a domain, selects high-signal pages, runs category-aware extraction passes, adds deterministic enrichment, records source attribution, and compares outputs with labeled examples.
public: Website extraction pipeline that builds structured company profiles with sources, screenshots, and completeness checks.
tags: Extraction Pipeline
keywords: startup extract, company knowledge base, firecrawl, website extraction, sources, provenance, pricing, screenshots, evals
use when: ## What it does This utility maps a company website, selects high-signal pages, and produces a structured knowledge base. The output can include company basics, product descriptions, pricing tiers, brand colors, screenshots, source URLs, field-level provenance, and a completeness score. ## Why split the pipeline Not every field needs an LLM. The extraction combines targeted model passes with deterministic parsing for things such as colors, logos, prices, calls to action, and change hashes. There is also a small evaluation path for comparing generated output with labeled examples. ## Implementation details - URLs are classified into page types such as home, about, products, pricing, resources, careers, legal, and contact before extraction. - The typed output model covers company basics, writing guidance, design assets, competition, positioning, culture, development, legal pages, products, and pricing. - Deterministic helpers normalize colors, discover likely logo assets, extract pricing signals, and calculate a completeness score. - The final JSON records source URLs and can attach field-level provenance for later review. ## Extract vs scrape The useful lesson was that "extract the company" is too vague. The repo ended up using two different modes: ```text Full extractor -> map the site, run richer Firecrawl extraction, merge deterministic signals, return CompanyKnowledgeBase Lite extractor -> scrape high-signal pages, gather heuristics, let a lightweight LLM polish a stakeholder-friendly summary ``` The distinction matters because some fields are semantic and some are mechanical: ```python # AI extraction is useful for mission, product descriptions, positioning. extracted = client.extract( urls=["https://example.com/", "https://example.com/pricing"], schema=FULL_COMPANY_SCHEMA, prompt="Extract company info, products, pricing, culture...", ) # Raw scraping is better for deterministic details. colors = re.findall(r"#[0-9a-fA-F]{6}", html_doc.html) ``` ## What I learned Extraction systems get better when the output admits where each fact came from. A pretty summary is not enough. The reviewer needs source URLs, screenshots, field-level provenance, and completeness checks so they can decide what to trust.

X Bookmark Brief

id: project:bookmarks-brief
path: /projects/bookmarks-brief
summary: A personal automation pipeline that scrapes X bookmarks, enriches them with structured metadata, and sends a weekly LLM-generated intelligence digest.
public: Personal pipeline that turns saved X bookmarks into a weekly brief with classifications, actions, and reflection prompts.
tags: Personal Automation
keywords: x bookmarks, twitter bookmarks, weekly brief, intelligence brief, llm pipeline, classification, reflection, personal automation
use when: ## Why I built it Saving useful posts had turned into passive accumulation. I wanted a system that would help me revisit ideas while they were still relevant to the things I was building and thinking about. ## How it works 1. A Playwright scraper saves bookmarks into SQLite. 2. An enrichment step adds deterministic metadata and optional LLM intent classification. 3. A weekly digest groups the useful items into a briefing, clustered sections, a chronological appendix, and a reflection prompt. 4. A small orchestration wrapper makes the pipeline repeatable enough to schedule. Different model stages are chosen for different jobs: inexpensive classification for volume, stronger synthesis for the weekly brief, and a smaller creative step for the reflection question. ## Implementation detail The pipeline is split into CLI stages so each part can be run, retried, or scheduled separately: ```text fetch_bookmarks.py -> scrape bookmarks into SQLite enrich_bookmarks.py -> add metadata and LLM intent labels send_weekly_digest.py -> generate and send the weekly brief run_pipeline.py -> orchestrate recurring runs ``` The orchestration wrapper uses a file lock so scheduled jobs do not overlap: ```python with path.open("w") as lock_file: fcntl.flock(lock_file.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB) try: yield finally: fcntl.flock(lock_file.fileno(), fcntl.LOCK_UN) ``` ## Reliability details - SQLite stores the original bookmark alongside enrichment status, fallbacks, and digest history. - A file lock prevents overlapping scheduled runs from racing each other. - Digest history makes it possible to resurface older posts without repeatedly recycling the same items. - Media previews are restricted to expected X image hosts. - A dry-run mode renders the digest locally before sending it. ## Prompt design The digest prompt is opinionated on purpose. It asks for a personal intelligence briefing, not a neutral summary. The useful output connects saved posts to current projects, repeated authors, and the collector-versus-builder tension in the bookmark data. The model policy is also split by cost and quality: ```text Intent classification: gpt-4o-mini Weekly briefing: gpt-5, fallback gpt-5-mini Reflection question: gpt-5-mini, fallback gpt-4o-mini ``` ## What matters to me This is less about scraping than building a better information diet. The pipeline is useful when it turns a saved link into an action, a connection, or a question worth following.

AI Fashion Content Studio

id: project:ai-fashion-content-studio
path: /projects/ai-fashion-content-studio
summary: A failed AI fashion content studio experiment: Flask, SQLite, Google OAuth, Fal API virtual try-on, image-to-video jobs, Socket.IO job updates, gallery ownership, and UGC video assembly.
public: Failed but useful Flask experiment for AI fashion try-ons, video generation, and UGC-style content workflows.
tags: AI Media
keywords: ai fashion, ai fashn, virtual try on, fashn, fal ai, ugc, fashion content, video generation, flask, socketio
use when: ![AI fashion content studio landing page](/project-media/ai-fashion-content-studio/landing.webp) ## The idea The bet was simple: e-commerce brands need more product and fashion content than they can afford to shoot manually. I tried to turn that into a small SaaS-style tool where a user could upload a model image and a garment image, generate try-on output, make short AI video variations, and save results into a gallery. It did not become a business. The useful part was learning what breaks when an AI media idea moves from "cool demo" to "actual workflow." ## What I built The app was a Flask project with user auth, a SQLite database, and several generation paths: - Virtual try-on jobs through the `fashn/tryon` model on Fal. - Image-to-video jobs through a Kling endpoint. - A user-owned gallery for generated try-ons, videos, and UGC clips. - Socket.IO rooms for job status updates. - A UGC composer that could merge an avatar/template video with a product video and optional caption text. ![AI fashion studio workspace](/project-media/ai-fashion-content-studio/studio.webp) ## Implementation detail The central pattern was job-first: save a database record, submit the generation request, then let the webhook update the job and gallery later. ```python new_job = TryOnJob( model_image_url=model_url, garment_image_url=garment_url, category=category, status="SUBMITTED", config=config, ) db.session.add(new_job) db.session.commit() handler = rate_limited_api_call( fal_client.submit, "fashn/tryon", arguments={ "model_image": model_url, "garment_image": garment_url, "category": category, **config, }, webhook_url=webhook_url, ) ``` The UGC path used FFmpeg-style processing through Python subprocess calls: trim the uploaded product video, scale it to match the template, optionally burn in a caption, concatenate the clips, and extract a thumbnail. ![AI fashion advanced settings](/project-media/ai-fashion-content-studio/settings.webp) ## Why it failed The core value proposition was too broad. It mixed virtual try-on, AI video, UGC management, subscriptions, and gallery behavior before any one user workflow was sharp enough. Technically, async generation also made the product surface harder than expected: upload validation, temporary files, webhook reliability, user ownership, generated asset expiry, and model quality variance all mattered more than the landing page implied. ## What stuck This was a good early lesson in AI product scope. The model call was the easy part. The actual product was the surrounding system: job state, fallbacks, ownership, previews, cleanup, and a UI that made failures understandable.

Local Service Website Outreach

id: project:local-service-website-outreach
path: /projects/local-service-website-outreach
summary: A failed but useful outreach experiment for selling websites to local service businesses, focused on mobile RV repair and mobile pet grooming niches, with niche research, landing page positioning, mock sites, pricing, and conversion copy.
public: Failed small-business website offer built around mobile RV repair and pet grooming niches, with mock landing pages and outreach positioning.
tags: Small Business
keywords: company site, accelerated devs, mobile rv repair, pet grooming, small business websites, outreach, local seo, landing page, pricing, calendly
use when: ![Mobile RV repair landing page mockup](/project-media/local-service-website-outreach/rv-repair.webp) ## The experiment This was an attempt to sell fast, mobile-friendly websites to local service businesses. The offer was not "I can code a website"; it was "your customers are searching online, your competitors have weak sites, and a simple local page can help you get chosen." The two clearest niches were mobile RV repair and mobile pet grooming because both had urgent, local-intent searches and businesses that often had weak or missing web presence. ## What I built The repo is a static Tailwind site for the offer, branded as Accelerated Devs. It included: - A main sales page with demand framing, service cards, pricing, process, and contact CTAs. - Niche-specific cards for mobile RV repair, mobile pet grooming, tiny homes, elder care, and other local businesses. - Mock landing pages to show what a finished client site could look like. - Calendly-style booking copy and a constrained "limited spots" offer. - Google Tag Manager wiring for basic funnel tracking. ![Mobile pet grooming landing page mockup](/project-media/local-service-website-outreach/pet-grooming.webp) ## The outreach thinking The project was more about positioning than engineering. I was trying to answer: 1. Which small businesses have enough search intent to care? 2. Which ones often have weak websites? 3. Can the offer be specific enough that a cold message feels relevant? 4. Can mockups make the pitch concrete before a client exists? The site copy was built around that logic: ```html <h3>Mobile RV Repair Services</h3> <p> RV owners need urgent repairs on the road. Only 40-50% of techs have websites, giving you a competitive edge. </p> ``` ![Animated showcase of mock websites](/project-media/local-service-website-outreach/site-demo.webp) ## Why it failed It did not turn into a repeatable business because the offer stopped at "better website" instead of owning a full lead-generation outcome. A local business does not really want a site. They want booked jobs, trust, and fewer dead-end inquiries. The next version would need a tighter vertical, real outreach volume, proof from one paying customer, and a stronger package around leads, booking, SEO, and follow-up. ## What I learned This was useful because it forced the work outside the code editor. The hard parts were niche selection, copy, proof, distribution, and trust. The website was only the artifact.

PoolPulse Conversion Demo

id: project:poolpulse-conversion-demo
path: /projects/poolpulse-conversion-demo
summary: A product demo for pool builders: lead capture, outbound email, inbound reply processing, structured sales-signal extraction, deterministic stage transitions, fallbacks, and an operator dashboard.
public: Lead-conversion demo for pool builders with AI-assisted qualification, email replies, and visible workflow state.
tags: Workflow Automation
keywords: poolpulse, pool builders, lead conversion, qualification, email, postmark, workflow, fallbacks, dashboard
use when: ## The problem Local service businesses can lose good leads when the first response is slow or when follow-up depends on somebody manually reading every message. ## What I built PoolPulse is a demo workflow for capturing a lead, sending first outreach, processing email replies, extracting sales signals, and moving the lead through explicit stages: `NEW -> CONTACTED -> QUALIFYING -> QUALIFIED -> BOOKED` The demo includes an operator view for inbox threads, pipeline movement, workflow events, and conversion analytics. ## Engineering choices - Inbound replies are idempotent and resolve back to a lead through email thread headers, an explicit lead reference, or sender fallback. - AI extracts schema-bound qualification fields and drafts natural replies. - Deterministic rules decide workflow state, unsupported project screening, opt-outs, follow-up timing, and when to hand the conversation to a person. - Taxonomy normalizers and fallback extraction keep the workflow usable when a model provider is unavailable. - The model registry supports multiple AI providers. - The service flow is covered with in-memory database tests for intake, qualification, booking, follow-ups, and email threading behavior. ## Implementation detail The core design was to keep workflow decisions deterministic and let the model handle language and extraction. For example, qualification fields are prioritized in code: ```ts const requiredQualificationFields = [ "budgetRange", "timeline", "poolType", "intent", ] export function computeMissingFields(fields) { return requiredQualificationFields.filter((field) => isUnknownValue(fields[field]) ) } ``` Unsupported projects are also rule-based: ```ts if (/\brepair\b|\bpool pump\b|\bheater\b|\bfilter\b|\bleak\b|\bfix\b/.test(text)) { return { supported: false, label: "Repair / service", reason: "Project is a repair or service request", } } ``` That made the demo easier to inspect: the AI can be wrong about extracted fields, but the state transition logic stays visible. ## What I was trying to prove The problem was speed-to-lead. A local service business can receive a decent inquiry and still lose it because the first reply is late, the follow-up is inconsistent, or nobody knows whether the lead is ready to book. PoolPulse tried to make that operational loop explicit: capture, reply, extract, decide, follow up, and show the operator what happened. ## Current boundary This is a product demo, not a finished sales system. Deliverability, domain-specific qualification rules, and the booking integration would need a deeper production pass.

Forman Management Review

id: project:forman-management-review
path: /projects/forman-management-review
summary: An older non-code leadership project: Ashter served as editor-in-chief for FCCU School of Management's first magazine, leading a 12-person team through concept, interviews, editing, design, outreach, sponsorship, and launch.
public: Editorial leadership project: helped launch FCCU School of Management's first magazine as editor-in-chief.
tags: Editorial Project
keywords: forman management review, business school magazine, editor in chief, fccu, school of management, editorial, leadership, magazine
use when: ![Forman Management Review cover](/project-media/forman-management-review/cover.webp) ## What it was Before most of the AI projects, I served as editor-in-chief for Forman Management Review, FCCU School of Management's first magazine publication. The goal was to create a serious management publication for the business school: interviews, essays, research-adjacent pieces, alumni voices, and a final issue that could become the template for future editions. The [digital edition](https://drive.google.com/file/d/1kL36KMHBjqSLHou8a3QPhHhBV7t1WNXa/view) is still available. ## What I was responsible for This was less about one deliverable and more about getting a new institution-level project from zero to launch. - Helped shape the concept and publication direction. - Led a 12-person team across writing, editing, interviews, design, outreach, and coordination. - Worked with professors, alumni, and professionals as contributors/interviewees. - Helped secure alumni sponsorship for most of the funding. - Set up the first issue as a foundation for future editions. ![Editor's note spread from Forman Management Review](/project-media/forman-management-review/editor-note.webp) ## Why it still belongs here It is not a coding project, but it is part of the same pattern I keep returning to: take an ambiguous thing, make it legible, coordinate people around it, and ship a public artifact. That same muscle shows up later in applied AI work. The medium changed from magazine pages to pipelines and agents, but the real skill was still turning scattered inputs into something coherent enough for other people to use.

Solar Rooftop Calculator

id: project:solar-rooftop-calculator
path: /projects/solar-rooftop-calculator
summary: A rooftop solar calculator that began as a Pakistan-focused polygon and NASA POWER estimator, then evolved into Watt If: a broader home-energy checkup with local tariffs, bill-driven sizing, battery scenarios, and payback comparisons.
public: Rooftop solar and home-energy estimator using satellite mapping, NASA POWER data, local tariffs, and scenario modeling.
tags: Geospatial Tool
keywords: solar, rooftop, watt if, home energy, pakistan, nasa power, pvlib, mapbox, geospatial, battery, payback
use when: ## 2026 update: Watt If I revisited the original calculator as [Watt If](https://watt-if.drenigma.chatgpt.site/#city=us-sf&bill=150&lat=37.775752&lng=-122.412388&z=19), a more complete and location-flexible home-energy checkup. It keeps the roof-tracing and solar-resource foundation while adding local tariffs and equipment prices, bill-driven system sizing, adjustable roof direction and shading, monthly energy-flow estimates, backup-battery scenarios, and a ten-year payback comparison. ![Watt If guided rooftop search, tracing, and electricity-bill setup](/project-media/solar-rooftop-calculator/watt-if-overview.webp) The shared example uses a San Francisco home and a $150 monthly bill to show the recommendation, energy and bill offsets, estimated installation cost, savings, and payback period. ![Watt If energy offset, monthly savings, installation cost, and payback results](/project-media/solar-rooftop-calculator/watt-if-results.webp) ## The idea Estimate the solar potential of a specific rooftop instead of asking somebody to reason from a rough address or property description. ![Solar calculator map, selected roof, and AI assistant context](/project-media/solar-rooftop-calculator/solar-map.webp) ## How it works Users draw a rooftop polygon on satellite imagery. The app calculates area, fetches location-specific solar radiation data from NASA POWER, applies `pvlib` models, and estimates annual energy production and financial savings. ![Short loop of selecting a rooftop and generating the estimate](/project-media/solar-rooftop-calculator/solar-flow.webp) ## What it combines - Mapbox satellite imagery and polygon drawing - Geospatial area calculations with Turf.js - NASA POWER irradiance data - Solar modeling with `pvlib` - A Python and Flask backend with cached calculations The main calculation converts hourly irradiance into plane-of-array estimates, then applies panel efficiency, system-loss, and usable-roof assumptions. Results are cached by rounded coordinates and year so nearby repeat calculations do not keep hitting the upstream API. ## Implementation detail The backend keeps the API small: the browser sends GeoJSON and measured area, the server finds the polygon centroid, calls the solar model for that coordinate, and scales the result by usable roof area. ```python centroid = shape(geometry).centroid area_m2 = float(data["area"]) kwh_per_m2, pkr_per_m2 = power_hourly(centroid.y, centroid.x) total_kwh = round(kwh_per_m2 * area_m2, 1) total_pkr = round(pkr_per_m2 * area_m2) ``` ## Graceful fallback If the upstream irradiance request or the full model fails, the app falls back to a simpler latitude-based estimate instead of leaving the user without a result. ## Installer assistant The prototype also passes available roof area, location, and savings context into an installer-recommendation assistant. It can query a small local knowledge base for region-aware recommendations and market information without asking the user to repeat details already captured by the map. The project is specific to Pakistan, where a practical estimate in local currency is more useful than a generic solar calculator.
link: https://watt-if.drenigma.chatgpt.site/#city=us-sf&bill=150&lat=37.775752&lng=-122.412388&z=19

Writing

Eval-Driven Development · Receipt Auditor

id: writing:medium:eval-driven-development-receipt-auditor-part-3
path: https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-608e88550996
summary: Part 3 of the receipt auditor case study: a perfect train-set score hid near-zero handwritten-X recall, class-balanced repeated evals exposed inconsistent detection, saved-output replay rejected a harmful fallback, and a measured model upgrade fixed the capability bottleneck.
keywords: receipt auditor, receipt evals, eval-driven, misleading scoreboards, handwritten x, recall, class balance, repeated runs, model selection, medium
date: Jul 10, 2026
link: https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-608e88550996

Eval Driven Development · Receipt Auditor

id: writing:medium:eval-driven-development-receipt-auditor
path: https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-part-2-3615f7a926c3
summary: Receipt auditor case study on reading eval scoreboards from the business outcome backward, moving closed-form audit decisions into deterministic code, separating receipt math errors from extraction warnings, and identifying extraction as the next eval frontier.
keywords: receipt auditor, receipt evals, eval-driven, business outcome, deterministic checks, audit routing, extraction quality, medium
date: Jun 19, 2026
link: https://medium.com/@ashterhaidernawaz/eval-driven-development-receipt-auditor-part-2-3615f7a926c3

Building an Eval-Driven Receipt Auditor From Scratch

id: writing:medium:building-eval-driven-receipt-auditor-from-scratch
path: https://medium.com/@ashterhaidernawaz/building-an-eval-driven-receipt-auditor-from-scratch-1d7065117f31
summary: Part 1 case study for the receipt auditor project: business framing, two-stage extraction and audit design, strict schemas, saved outputs, visible failure modes, and business-impact-centered eval thinking.
keywords: receipt auditor, receipt evals, eval-driven, baseline, structured outputs, audit routing, business impact, medium
date: Jun 6, 2026
link: https://medium.com/@ashterhaidernawaz/building-an-eval-driven-receipt-auditor-from-scratch-1d7065117f31

intelligence too cheap to meter

id: writing:substack:intelligence-too-cheap-to-meter
path: https://ashterhaider.substack.com/p/intelligence-too-cheap-to-meter
summary: A thesis piece for the receipt auditor series: as intelligence gets cheaper and AI systems become easier to ship, judgment, evals, escalation, and production reliability become more valuable.
keywords: cheap intelligence, judgment, evals, receipt auditor, ai reliability, escalation, production ai, substack
date: Jun 5, 2026
link: https://ashterhaider.substack.com/p/intelligence-too-cheap-to-meter

not just anything

id: writing:substack:not-just-anything
path: https://ashterhaider.substack.com/p/not-just-anything
summary: An essay about why reducing AI to next-token prediction can be technically accurate while still leaving out the more interesting question of what complex behavior emerges from a mechanism.
keywords: not just anything, next token prediction, ai, intelligence, predictive coding, emergence, mechanism
date: Mar 2, 2026
link: https://ashterhaider.substack.com/p/not-just-anything

run the next token

id: writing:substack:run-the-next-token
path: https://ashterhaider.substack.com/p/run-the-next-token
summary: A personal essay published on Substack under the subtitle SOUL.md.
keywords: run the next token, soul md, ai, substack, essay
date: Feb 23, 2026
link: https://ashterhaider.substack.com/p/run-the-next-token

I thought of you

id: writing:substack:i-thought-of-you
path: https://ashterhaider.substack.com/p/i-thought-of-you
summary: Issue 1 of Ashter's short building-in-public series.
keywords: i thought of you, building in public, substack, issue 1
date: May 11, 2025
link: https://ashterhaider.substack.com/p/i-thought-of-you

What I Wish Someone Had Told Me

id: writing:substack:what-i-wish-someone-had-told-me
path: https://ashterhaider.substack.com/p/what-i-wish-someone-had-told-me
summary: A personal reflection written after turning 23, meant as advice Ashter wanted to preserve for his future self.
keywords: what i wish someone had told me, turning 23, life advice, reflection, personal essay
date: Dec 24, 2024
link: https://ashterhaider.substack.com/p/what-i-wish-someone-had-told-me

FIVE at 9 archive

id: writing:substack:five-at-9-archive
path: https://ashterhaider.substack.com/
summary: An older weekly Substack series that collected ideas, quotes, and things Ashter wanted to remember.
keywords: five at 9, archive, quotes, ideas, substack, newsletter
date: 2023
link: https://ashterhaider.substack.com/