ResuGenie started as a 24-hour hackathon project. It won first place against 50+ teams. Then came the real challenge: turning a hackathon prototype into a production AI system on AWS. The gap between those two things is wider than most people realize.

What ResuGenie Does

ResuGenie is an AI-powered resume intelligence system. It parses resumes, extracts structured information, and performs semantic matching between resumes and job descriptions. Not keyword matching semantic matching. A resume that says "built distributed systems" should match a JD that says "experience with scalable infrastructure" even without keyword overlap.

The hackathon version was a Flask app running locally with a SQLite database and OpenAI API calls. It worked beautifully in the demo. It would have collapsed under any real load.

The Production Architecture

Moving to production required a complete architectural redesign:

+-------------+     +------------------+     +-----------------+
   AWS ECS   ----?  Amazon Bedrock  ----?  AWS OpenSearch 
   Fargate          (Claude model)         (Vector Store) 
+-------------+     +------------------+     +-----------------+
                                                     
       →                                              ?
+-------------+                           +-----------------+
   AWS S3                                 kNN Vector     
  (Storage)                               Similarity     
+-------------+                           +-----------------+

AWS ECS Fargate: The Deployment Layer

The hackathon app was a single Python process. Production needed horizontal scaling, health checks, rolling deployments, and zero-downtime updates.

I chose ECS Fargate over EC2 for a specific reason: Fargate is serverless containers you define the task, AWS manages the underlying infrastructure. No server provisioning, no AMI management, no capacity planning for the container host.

Key Fargate configuration:

# Task definition (simplified)
{
    "family": "resugenie-task",
    "networkMode": "awsvpc",
    "requiresCompatibilities": ["FARGATE"],
    "cpu": "1024",   # 1 vCPU
    "memory": "2048",  # 2 GB
    "containerDefinitions": [{
        "name": "resugenie",
        "image": "ACCOUNT.dkr.ecr.REGION.amazonaws.com/resugenie:latest",
        "portMappings": [{"containerPort": 8000}],
        "environment": [
            {"name": "OPENSEARCH_HOST", "value": "..."},
            {"name": "AWS_REGION", "value": "us-east-1"}
        ]
    }]
}

Amazon Bedrock: The LLM Layer

The hackathon version used OpenAI's API directly. Production moved to Amazon Bedrock for two reasons: data privacy (resumes are sensitive documents and we wanted them to stay within our AWS environment) and cost predictability.

Bedrock provides managed access to foundation models Claude, Titan, Mistral with IAM authentication instead of API keys, which integrated cleanly with our existing AWS security posture.

OpenSearch: The Vector Store

The core intelligence of ResuGenie is semantic matching comparing embeddings of resume sections to embeddings of job description requirements. AWS OpenSearch (managed Elasticsearch) supports k-NN vector search natively.

Every resume section is embedded and stored. When a JD comes in, we embed each requirement and query OpenSearch for the closest matching resume sections. The results are scored and assembled into a match report.

def match_resume_to_jd(resume_sections, jd_requirements):
    scores = []
    for requirement in jd_requirements:
        req_embedding = embed_text(requirement)
        
        # Find closest resume section
        results = opensearch.search(
            index="resume-embeddings",
            body={
                "query": {
                    "knn": {
                        "embedding": {
                            "vector": req_embedding,
                            "k": 1
                        }
                    }
                }
            }
        )
        
        best_match = results["hits"]["hits"][0]
        scores.append({
            "requirement": requirement,
            "matched_section": best_match["_source"]["text"],
            "score": best_match["_score"]
        })
    
    return scores

The Challenges: Prototype to Production

Three specific problems the hackathon version didn't face:

• Cold start latency: Fargate tasks take 30-60 seconds to start. For a demo this is fine. For production, you need minimum running tasks and auto-scaling policies that pre-warm capacity.
• Embedding costs: Embedding every resume and JD has real API cost. We implemented caching same text hash gets the cached embedding, not a new API call.
• Resume format diversity: Hackathon resumes were clean PDFs. Production resumes arrive as .docx, .pdf with images, scanned documents, two-column layouts. Parsing became its own engineering problem.

What the Hackathon Didn't Teach

The hackathon taught me that the idea worked. Production taught me everything else: infrastructure, scaling, observability, cost optimization, error recovery, and the endless variety of real-world inputs.

If I had to summarize the lesson in one sentence: a prototype proves the concept; production proves the engineering. They require completely different skills.