Hashi Warsame Blog

Building an AI Scholarship Matching Platform with Claude

Mon, 11 May 2026 00:00:00 GMT

Every year, billions of dollars in scholarship funding goes unclaimed — not because students aren't deserving, but because the matching problem is genuinely hard. Eligibility criteria span citizenship, GPA thresholds, field of study, programme level, and dozens of softer factors that no spreadsheet can sensibly aggregate. Whizzia is our answer to that problem: an AI-powered scholarship intelligence platform that maps a student's full academic profile to a ranked shortlist of opportunities, then helps them actually win.

You can see the live app here: WhizzIA

I'm the lead developer on the project. Here's how we built it.

The Core Idea

The platform sits at the intersection of three problems students face:

Discovery — finding scholarships they're actually eligible for, not just a generic list
Positioning — understanding how competitive their profile is and what's missing
Application quality — getting their CV and personal statement to a fundable standard

Claude handles all three. The architecture is a Next.js frontend talking to a Supabase backend, with the Claude API powering the intelligence layer — profile analysis, CV critique, essay feedback, and scholarship scoring.

Authentication and Onboarding

The entry point is a clean split-screen login. A dark teal panel on the left carries the Whizzia logo — a graduation cap overlaid on a location pin, which neatly encodes the "where are you going?" question at the heart of the product. The right panel handles the email OTP flow.

We deliberately avoided social login for the first version. Scholarship applications involve sensitive data — GPA, citizenship, disability status — and a verified email creates a cleaner audit trail. The six-digit OTP is sent via Supabase Auth and expires in ten minutes.

// pages/api/auth/verify.ts
const { data, error } = await supabase.auth.verifyOtp({
  email,
  token: otp,
  type: 'email',
});

The Profile Builder

Once authenticated, students are walked through a seven-step profile wizard. Step one collects the demographic information that gates the largest share of scholarships: country of citizenship, country of residence, gender, ethnicity (optional), and disability status.

The sidebar shows progress through all seven steps — Personal Information, Academic Background, Study Preferences, Work Experience, Research & Projects, Achievements, and Final Details. A live Profile Readiness score in the top-right corner updates as fields are completed, climbing toward 100% as the student fills in more data. This was a deliberate UX choice: visible progress reduces drop-off in long onboarding flows.

Subsequent steps capture the academic data that drives matching: GPA, current degree level, target programme, intended study destination, language proficiency scores, and a free-text personal statement. Work experience and research sections feed directly into the CV review feature.

All profile data is stored in Postgres via Supabase. No data is sent to Claude unless the user explicitly triggers an analysis — privacy by default.

Profile Analysis and Scholarship Readiness

The Profile Analysis page is the dashboard's centrepiece. It surfaces four headline metrics — Completeness, Readiness score, Percentile rank, and total Match count — alongside a breakdown of what's still missing and an Eligibility Alignment panel.

The Scholarship Matches widget in the bottom right categorises opportunities into three buckets: Safe (18), Competitive (23), and Reach (9). These aren't static labels — they're computed at query time by comparing the student's normalised profile vector against each scholarship's eligibility matrix. The bucketing thresholds are tuned to the realistic acceptance rates in our dataset.

The "Missing Critical Data" banner is generated by a lightweight rules engine that checks which high-signal fields are empty. Country of citizenship, GPA, programme level, field of study, study destination, and personal statement are the six fields with the most impact on match quality — filling them shifts the match count from 50 to upwards of 120 in most cases.

const CRITICAL_FIELDS = [
  { key: 'citizenship', label: 'Country of citizenship' },
  { key: 'gpa', label: 'GPA' },
  { key: 'programLevel', label: 'Program level' },
  { key: 'fieldOfStudy', label: 'Field of study' },
  { key: 'destination', label: 'Study destination' },
  { key: 'statement', label: 'Personal statement' },
];

export function getMissingCritical(profile: Profile) {
  return CRITICAL_FIELDS.filter(f => !profile[f.key]);
}

CV Review with Claude

The CV Review flow is a three-step pipeline: upload, AI analysis, template selection. Students drag in a PDF, DOC, DOCX, or TXT file (up to 10 MB), hit Analyse My CV, and within seconds get a structured critique from Claude.

The AI Insights panel on the right is empty until a CV is uploaded — a deliberate holding state that signals "your analysis lives here." Once the document is processed, Claude returns a structured JSON object covering: overall strength score, section-by-section feedback, missing scholarship-relevant keywords, and three specific improvement actions ranked by impact.

const systemPrompt = `You are an expert scholarship application advisor. 
Analyse the student's CV for scholarship competitiveness.
Return a JSON object with this exact shape:
{
  "overallScore": number,          // 0-100
  "summary": string,               // 2-3 sentence executive summary
  "sections": [                    // per-section feedback
    { "name": string, "score": number, "feedback": string }
  ],
  "missingKeywords": string[],     // scholarship-relevant terms not present
  "topActions": [                  // ranked improvement actions
    { "priority": number, "action": string, "impact": string }
  ]
}
Return only valid JSON. No preamble, no markdown fences.`;

const response = await fetch('https://api.anthropic.com/v1/messages', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 1000,
    system: systemPrompt,
    messages: [{ role: 'user', content: cvText }],
  }),
});

The previous analyses section below the upload zone shows a history of past CV versions with their scores, letting students track improvement over time. This has been one of the most-used features in early testing — students revise based on feedback, re-upload, and watch their score climb.

Essay Review

The Essay Review module follows the same pattern as CV Review but is tuned specifically for scholarship personal statements. Claude evaluates the essay against five scholarship-specific rubrics: clarity of purpose, evidence of impact, fit with the target award's values, narrative coherence, and differentiation from a hypothetical applicant pool.

The prompt instructs Claude to return feedback structured around the specific scholarship the student is applying for — if a student has indicated they're targeting a Commonwealth Scholarship, the feedback prioritises community impact and development goals over raw academic achievement.

Scholarship Matching Engine

The matching logic runs in two passes. The first is a hard-filter pass in SQL — ruling out any scholarship where the student doesn't meet mandatory criteria (citizenship, GPA floor, degree level). The second is a soft-ranking pass using Claude, which takes the filtered shortlist and the student's profile and returns a ranked list with per-scholarship reasoning.

const rankingPrompt = `
Given the following student profile and list of scholarships they are 
eligible for, rank the scholarships by fit and return a JSON array.
For each scholarship, include:
- scholarshipId
- fitScore (0-100)  
- keyStrengths (array of strings — why this student is a good fit)
- keyRisks (array of strings — what might count against them)
- recommendedFocus (string — what to emphasise in the application)

Student profile: ${JSON.stringify(profile)}
Eligible scholarships: ${JSON.stringify(eligibleScholarships)}
`;

This two-pass approach keeps costs predictable — the SQL filter reduces the average shortlist from 400+ scholarships to around 50 before Claude ever sees it, keeping token usage per ranking call under 3,000.

What's Next

The roadmap has three near-term priorities. First, a deadline tracker integrated into the Checklist feature — scholarship windows are brutally short and students consistently miss them. Second, a recommendation letter assistant that drafts referee briefing documents, giving students a polished summary of their accomplishments to hand to professors. Third, a mock interview module using Claude's conversational capability to run practice scholarship interviews for high-value awards like Rhodes and Gates Cambridge that include a panel stage.

The infrastructure is largely in place. The interesting work now is in the product layer — understanding precisely what blocks a student between "matched" and "funded," and building the features that close that gap.

Built by Hashi Warsame — Lead Developer, Whizzia

How I Built an AI Health Risk Dashboard with Claude

Mon, 11 May 2026 00:00:00 GMT

Heart disease is notoriously difficult to catch early — not least because the highest-risk patients are often the ones showing no symptoms at all. In this project we build a Heart Disease Risk Intelligence Dashboard that visualises the UCI Cleveland dataset across 303 patients and uses the Claude API to surface the patterns a human analyst might miss.

You can see the live dashboard here: tiny-biscuit-82b936.netlify.app

The Dataset

The dataset comes from the UCI Cleveland Clinic Heart Disease study. It contains 303 patient records with 14 clinical features including age, sex, chest pain type, resting blood pressure, serum cholesterol, and maximum heart rate achieved. 165 of the 303 patients tested positive for heart disease, giving a prevalence rate of 54.5%.

All the raw data is baked directly into the dashboard as a JavaScript object, keeping the project dependency-free and instantly deployable.

const DATA = {
  age: [
    { label:'< 45',  rate:20,   d:12,  t:58  },
    { label:'45–54', rate:44,   d:39,  t:88  },
    { label:'55–64', rate:62,   d:60,  t:97  },
    { label:'65+',   rate:72,   d:43,  t:60  },
  ],
  cp: [
    { label:'Typical Angina',    rate:28, d:8,  t:23 },
    { label:'Atypical Angina',   rate:42, d:21, t:50 },
    { label:'Non-anginal Pain',  rate:47, d:39, t:86 },
    { label:'Asymptomatic',      rate:75, d:105,t:144 },
  ],
  // ...scatter and donut data
};

KPI Cards with Animated Counters

The four headline numbers at the top of the dashboard animate up from zero on load using GSAP. Each card reads its target value from a data-val attribute, so adding a new metric is as simple as dropping in a new card element.

function counter(el, to, sfx, dur = 1.5) {
  const float = String(to).includes('.');
  gsap.to({ v: 0 }, {
    v: to, duration: dur, ease: 'power3.out',
    onUpdate: function () {
      el.textContent =
        (float
          ? this.targets()[0].v.toFixed(1)
          : Math.round(this.targets()[0].v)) + sfx;
    }
  });
}

Scroll-triggered versions of the same function fire when each chart card enters the viewport, so numbers only count up once they're actually visible.

Bar Charts and the Scatter Plot

The bar charts are built from plain HTML and CSS — no charting library needed. Each bar starts at width: 0 and expands to its target percentage via a CSS transition triggered by a ScrollTrigger callback. Bars are coloured red when prevalence exceeds 50% and slate otherwise, giving an immediate at-a-glance risk signal.

function mkBars(id, items) {
  const el = document.getElementById(id);
  el.innerHTML = items.map(d => `
    <div class="group space-y-1.5 cursor-default">
      <div class="flex justify-between text-[11px] font-bold uppercase tracking-wider text-slate-500">
        <span>${d.label}</span>
        <span class="font-mono">${d.rate}% (${d.d}/${d.t})</span>
      </div>
      <div class="h-3 bg-slate-100 rounded-full overflow-hidden">
        <div class="h-full rounded-full transition-all duration-1000"
             style="width:0; background:${d.rate > 50 ? '#dc2626' : '#64748b'};"
             data-w="${d.rate}">
        </div>
      </div>
    </div>`).join('');

  ScrollTrigger.create({ trigger: el, start: 'top 95%', once: true,
    onEnter: () => el.querySelectorAll('[data-w]').forEach((b, i) =>
      setTimeout(() => b.style.width = b.dataset.w + '%', i * 80))
  });
}

The scatter plot is raw SVG. Each patient is a <circle> element positioned by age on the x-axis and maximum heart rate on the y-axis, coloured red for positive and blue for negative. Points animate in with a staggered GSAP fade and respond to hover with a tooltip showing the individual's age, heart rate, and diagnosis.

The AI Insights Panel

The most interesting part of the dashboard is the AI panel, which calls the Claude API to generate a clinical summary of the dataset on load. The response streams back character-by-character using a typewriter effect, giving it the feel of a live analysis rather than static text.

async function runAI() {
  const el = document.getElementById('ai-text');
  el.innerHTML = `<span class="text-slate-400">Crunching 303 patient records...<span class="cursor"></span></span>`;

  // Response is typed out character by character
  setTimeout(() => {
    el.textContent = '';
    el.classList.add('cursor');
    let i = 0;
    function type() {
      if (i < raw.length) {
        el.innerHTML += raw[i];
        i++;
        setTimeout(type, 6);
      } else {
        el.classList.remove('cursor');
      }
    }
    type();
  }, 800);
}

setTimeout(runAI, 1000);

Claude picks out three key findings from the data: the asymptomatic blind spot (75% positive rate among patients showing no symptoms), the early decline in maximum heart rate visible from age 45 onwards, and the 240 mg/dl serum cholesterol threshold above which 72% of positive cases cluster. A Refresh button lets you re-run the analysis at any time.

Styling and Animation

The visual identity leans on a tight palette of off-white, slate, and crimson. A subtle paper texture is applied via an SVG feTurbulence filter fixed to the viewport, giving the dashboard a tactile editorial feel without any image assets. Every card lifts slightly on hover through a shared hover-card class.

.hover-card {
  transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1),
              box-shadow 0.3s cubic-bezier(0.4, 0, 0.2, 1);
}
.hover-card:hover {
  transform: translateY(-4px);
  box-shadow: 0 14px 28px -10px rgba(15, 23, 42, 0.12);
}

Fonts are served from Google Fonts: Playfair Display for the large numerics and headings, Inter for body copy, and JetBrains Mono for the model tag and raw numbers in the charts.

Dataset source: UCI Cleveland Heart Disease · Kaggle

Built by Hashi Warsame

How I built a Neural Network from Scratch in Rust

Sun, 09 Mar 2025 00:00:00 GMT

AI often feels like magic, but beneath the surface, it's just a combination of mathematical foundations and code. In this post, we'll build a neural network from scratch in Rust — no ML libraries, just math and well-structured code.

The Matrix Structure

To handle the math, we first define our Matrix structure. We use a flat Vec to represent the matrix data, which is more cache-friendly than a vector of vectors. From this base struct we implement the core operations we'll need throughout the network: dot products, addition, and subtraction.

pub struct Matrix {
    pub rows: usize,
    pub cols: usize,
    pub data: Vec<f64>,
}

impl Matrix {
    pub fn dot_multiply(&self, other: &Matrix) -> Matrix {
        // ... implementation of matrix multiplication
    }
}

The Network Architecture

Our Network struct uses the Matrix type to manage the weights and biases between layers. It also holds the learning rate and the chosen activation function. The feed_forward method handles transforming input data through each layer in sequence, producing the final prediction.

pub struct Network {
    pub layers: Vec<usize>,
    pub weights: Vec<Matrix>,
    pub biases: Vec<Matrix>,
    pub activation: Activation,
    pub learning_rate: f64,
}

impl Network {
    pub fn feed_forward(&mut self, inputs: Matrix) -> Matrix {
        // Compute output by passing data through layers
        // Using our dot_multiply implementation
    }
}

Backpropagation

The most critical part of learning is backpropagation. After a forward pass we compute the error between the prediction and the target, then propagate that error backwards through each layer. At each step we calculate the gradient and apply it to the weights and biases via gradient descent, nudging them in the direction that reduces the error.

pub fn back_propagate(&mut self, inputs: Matrix, targets: Matrix) {
    let errors = targets.subtract(&inputs);

    // Iterate through layers in reverse
    for i in (0..self.layers.len() - 1).rev() {
        // Apply gradient descent
        self.weights[i] = self.weights[i].add(&gradients);
    }
}

The key fields driving this process are the layer topology (e.g. [2, 3, 1]), the weight matrices representing connection strengths, the bias vectors that shift each activation, and the activation function itself which introduces the non-linearity the network needs to learn complex patterns.

Training the Model

Finally, we loop through our training data over several epochs. On each pass the network runs a forward prediction, measures its error, and backpropagates to improve. After 10,000 epochs the weights have converged and the network reliably predicts the correct outputs.

fn main() {
    let mut network = Network::new(vec![2, 3, 1], Activation::SIGMOID, 0.5);

    // Train the network 10,000 times
    network.train(inputs, targets, 10000);

    println!("Training complete!");
}

Final Result

Watch the full step-by-step video tutorial below:

YouTube

Building a Web Server from Scratch in Rust

Mon, 08 Jul 2024 00:00:00 GMT

We often rely on frameworks like Actix and Rocket to build web applications, but do you know what is happening under the hood? In this post, we'll strip away the abstractions and build a functional web server from scratch in Rust to understand the foundations of HTTP and TCP.

The Networking Stack (OSI Model)

To understand web servers, we first need to look at the OSI Model, which breaks computer networking into seven layers. For a web server, the two most critical layers are the Transport Layer (Layer 4), which manages the actual delivery of data using protocols like TCP, and the Application Layer (Layer 7), where protocols like HTTP define how the client and server communicate.

Setting up a TCP Listener

The core of every web server is a TCP Listener. We use Rust's standard library to bind to a port and listen for incoming connections. For each accepted connection, we spawn a new thread to handle it concurrently so the main loop remains free to accept the next client.

use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    for stream in listener.incoming() {
        match stream {
            Ok(stream) => {
                std::thread::spawn(move || handle_client(stream));
            }
            Err(e) => println!("Error: {}", e),
        }
    }
}

Handling Client Requests

When a client connects, we read the incoming byte stream into a buffer and then parse it into a structured Request type. This struct captures the HTTP method (e.g., GET, POST), the requested URI, the HTTP version, any headers, and an optional body. From there we can inspect the request and generate an appropriate Response.

pub struct Request {
    pub method: HttpMethod,
    pub uri: String,
    pub version: String,
    pub headers: HashMap<String, String>,
    pub body: Option<String>,
}

Routing and Middleware

To make our server useful, we need a way to map specific URL paths to handler functions. We achieve this with a HashMap of routes keyed by path and HTTP method. We can also define a Middleware trait to intercept requests and responses — useful for cross-cutting concerns like logging or authentication without cluttering individual route handlers.

pub trait Middleware: Send + Sync {
    fn on_request(&self, request: Request) -> FutureRequest;
    fn on_response(&self, response: Response) -> FutureResponse;
}

Running the Server

Finally, we instantiate our server, bind it to an address, and register our routes. For handling multiple concurrent connections efficiently, we can swap raw threads for Tokio — Rust's async runtime — which gives us non-blocking I/O without the overhead of spawning a thread per connection.

#[tokio::main]
async fn main() {
    let addr = SocketAddr::from(([127, 0, 0, 1], 8080));
    let server = ServerBuilder::new()
        .bind(addr)
        .route("/", HttpMethod::GET, hello_handler)
        .build();

    server.run().await.unwrap();
}

Watch the full step-by-step video tutorial below:

YouTube