Why Build Something That Might Not Succeed?

Every ambitious project starts with a simple question. For us, it was: Why doesn’t Canada have a unified AI platform for science?

The US has one. Just days ago, the Department of Energy launched the Genesis Mission, an initiative to integrate AI capabilities across American national laboratories. It is a bold vision: connect data, compute, and researchers to accelerate discovery in energy, climate, and health.

Canada has the pieces. World-class research institutions. Supercomputing facilities in Montreal, Toronto, and Edmonton. A thriving AI ecosystem. But no unified platform connecting them. Data siloed across provinces. Researchers navigating a fragmented landscape of compute clusters. Potential for AI-driven breakthroughs sitting untapped.

NORAI (Nord/North AI) is our attempt to change that conversation. Not by waiting for government to act, but by building something tangible that shows what could exist.

The Vision

NORAI envisions doubling Canadian scientific productivity within a decade by integrating scientific datasets, laboratories, and supercomputers from coast to coast under one secure, bilingual, Indigenous-consent-aware national platform.

The platform addresses five critical Canadian science priorities:

1. Permafrost & Northern Infrastructure Resilience - Predicting infrastructure failures 10+ years in advance
2. Fusion Energy & Critical Minerals - Accelerating research into clean energy and resource independence
3. Pan-Canadian Cancer & Health Intelligence - Unified health data platforms for breakthrough treatments
4. Climate & Ice Prediction - 1-km resolution climate modeling
5. Sovereign Quantum & Semiconductor Design - Canadian-controlled advanced computing

The Project: Start Small, Think Big

Grand visions need concrete starting points. Ours is a web application designed to:

• Communicate the vision clearly to researchers, policymakers, and the public
• Gather interest from potential partners and stakeholders
• Demonstrate what a bilingual, accessible Canadian platform could look like
• Learn by building rather than just planning

Why These Technology Choices:

┌─────────────────────────────────────────────────────────────┐
│                       NORAI WEBSITE                          │
├─────────────────────────────────────────────────────────────┤
│  Framework:    Next.js 15 (App Router, TypeScript)          │
│  Styling:      Tailwind CSS 4 (Northern/Arctic theme)       │
│  i18n:         next-intl (English/French bilingual)         │
│  Animations:   Framer Motion                                │
│  Charts:       Highcharts                                   │
└─────────────────────────────────────────────────────────────┘

• Next.js 15 because a Canadian platform must be fast and accessible from Yellowknife to Halifax
• next-intl because bilingualism is not optional, it is foundational to Canadian identity
• Tailwind with a Northern theme because visual identity matters when speaking to government
• TypeScript because infrastructure code demands reliability

Key Features

Homepage

• Hero section with animated aurora background
• Stats showcasing the scale: 17+ Labs, 200 MW Compute, $2.5B Investment target
• Overview of the 5 Grand Challenges
• Platform architecture visualization

Challenges Page

• Detailed breakdown of each scientific priority
• Impact metrics and potential outcomes
• Canadian-specific context for each challenge

Platform Architecture

• 5-layer sovereign architecture:
  1. National Semantic Layer (knowledge graph)
  2. Federated Data Lakehouse (distributed storage)
  3. Secure Multi-Party Compute Enclave
  4. Borealis Model Family (Canadian-trained AI)
  5. NORAI Studio (researcher interface)

Computome Initiative

• Unified gateway for Canadian HPC resources
• Routes jobs across national clusters (Cedar, Narval, Niagara, Graham, Beluga)
• Startup-friendly pricing ($1/GPU-hour vs $3+ on AWS)
• Free tier for students and Indigenous communities

What Makes NORAI Different

While inspired by the Genesis Mission, NORAI is designed with Canadian values:

• Federated Model: Makes provincial fragmentation a strength (resilience + choice)
• Indigenous Priority: OCAP (Ownership, Control, Access, Possession) principles built-in
• Bilingual Operations: Full English/French/Inuktitut support
• Carbon-Optimized: Intelligent routing based on queue time, data locality, and carbon footprint
• Data Sovereignty: PIPEDA compliance with enforced geographic boundaries

The Honest Reality: Why We Build Anyway

Let us be direct: NORAI might not succeed.

Building national infrastructure requires government buy-in, significant funding, and coordination across provinces with different priorities. We are a small team with a website, not a government agency with a budget.

So why build it?

Because the alternative is waiting. Waiting for someone else to start. Waiting for perfect conditions. Waiting while other countries build their AI infrastructure and Canada falls behind.

What we gain regardless of outcome:

1. Learning by doing - Every line of code teaches us about platform design, accessibility, and bilingual development. These skills transfer even if NORAI never becomes a national platform.

2. Starting conversations - A working prototype opens doors that a slide deck cannot. Researchers and policymakers can see and interact with the vision.

3. Demonstrating possibility - Sometimes people need to see something exist before they believe it could exist at scale.

4. Building in public - Transparency about challenges invites collaboration. Someone reading this might have the connections or resources we lack.

The spectrum of outcomes:

• Worst case: A well-designed website that showcases Canadian AI ambitions and teaches us Next.js
• Middle case: A catalyst for conversations that lead others to build something better
• Best case: A prototype that attracts enough interest to become real infrastructure

All three outcomes are worth the effort.

Development Approach

The project follows a phased roadmap:

Phase 0: Foundation (Current)

• Website v1 with core messaging
• Legal and branding setup
• Initial outreach to potential partners

Phase 1: MVP Platform

• Partner dashboard
• Initial dataset integrations
• Pilot with 1 university + 1 Indigenous group
• Goal: 1,000 visitors, 50 letters of intent

Phase 2: Government Proposal

• Submission to ISED Sovereign Compute Initiative
• Expanded partnership network
• Technical prototype demonstrations

What We Have Learned So Far

Even in early development, the project has taught us:

• Bilingual development is harder than it looks - It is not just translation. It is rethinking UI layouts, handling text expansion, and respecting cultural context.
• Government-friendly design requires restraint - The temptation to add flashy animations fights against the need for accessibility and professionalism.
• Vision documents are easier than working code - Writing a whitepaper about federated data lakehouses is simpler than actually building one.
• The Canadian tech community is supportive - Early conversations have been encouraging, even when people are skeptical about outcomes.

Conclusion

NORAI is an experiment in building something ambitious with humble beginnings.

Canada has the talent. The resources. The need. What it lacks is a unified platform connecting them. Maybe NORAI becomes that platform. Maybe it inspires someone else to build something better. Maybe it just teaches us how to build bilingual Next.js applications really well.

All of those are fine.

Sometimes the best way to advocate for an idea is to start building it. The code is open. The vision is clear. The outcome is uncertain.

That is exactly how interesting projects should start.

From Localhost to the World: Using ngrok with Your Flask Application

If you have ever built a Flask application, you are probably familiar with the traditional http://localhost:5000 URL that greets you during development. It works great for testing on your own machine, but what happens when you need to share your work, test a webhook, or simulate real-world conditions? That’s where ngrok comes in.

What is ngrok?

ngrok is a tool that creates a secure tunnel from a public URL to your local machine. In simple terms, it takes your locally running application and makes it accessible to anyone on the internet through a generated URL.

Setting Up a Simple Flask App

Let’s start with a basic Flask application:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(debug=True)

Run this with python app.py (or with flask run), and you will see your app running at http://localhost:5000

Using ngrok

To expose your Flask app to the world, first install ngrok from ngrok.com. After creating a free account and authenticating with your token, simply run:

ngrok http 5000

You’ll see output like this:

Session Status                online
Account                       your-email@example.com (Plan: Free)
Version                       3.x.x
Region                        United States (us)
Forwarding                    https://a1b2c3d4.ngrok-free.app -> http://localhost:5000

That https://a1b2c3d4.ngrok-free.app URL is now publicly accessible and points directly to your local Flask application.

Why Use ngrok Instead of Localhost?

Why use ngrok when localhost works perfectly fine? Here are the scenarios where ngrok becomes invaluable:

Webhook Testing

Services like Stripe, GitHub, Twilio, and Slack need to send data to your server via webhooks. These services can’t reach localhost because it only exists on your machine. With ngrok, you get a real URL that these services can actually hit.

Sharing Work-in-Progress

Need to show a client or colleague what you’ve been working on? Instead of deploying to a staging server, just share your ngrok URL. They can see your latest changes in real-time as you make them, and it looks much better than just showing them a localhost address

Mobile Device Testing

Testing a responsive design on an actual phone? Your phone cannot access your computer’s localhost, but it can access an ngrok URL! Connect to the same network and open the ngrok URL on the device.

CORS and Cross-Origin Testing

Browsers treat localhost differently than real domains. If you are building an API that will be called from a different origin, testing with ngrok gives you more realistic CORS behavior. Some browser security features are relaxed for localhost, which can mask issues that will appear in production.

HTTPS Out of the Box

ngrok provides HTTPS automatically. This is crucial for testing features that require secure contexts, like geolocation APIs, service workers, or payment integrations. No need to set up SSL certificates locally.

Important: Free Tier Limitations

One thing to keep in mind is that the free tier of ngrok generates a random URL each time you start it. If you run ngrok http 5000 today, you might get https://a1b2c3d4.ngrok-free.app. Tomorrow, it will be a completely different URL like https://x9y8z7w6.ngrok-free.app.

This means:

• You will need to update webhook configurations each session
• Shared links will stop working when you restart ngrok
• Bookmarks will not persist between sessions

If you need a static URL, ngrok offers paid plans with custom domains and reserved subdomains.

Useful ngrok Commands

Here are some commands you’ll find helpful:

# Basic tunnel to port 5000
ngrok http 5000

# Tunnel with a specific region (for lower latency)
ngrok http 5000 --region eu

# View your active tunnels and request history
# Open http://localhost:4040 in your browser

# Replay a previous request (useful for webhook debugging)
# Available through the localhost:4040 interface

The ngrok Web Interface

One of ngrok’s best features is its local web interface at http://localhost:4040. This dashboard shows you:

• All incoming requests to your tunnel
• Request and response headers
• Body content
• Response times
• The ability to replay requests

This is incredibly useful for debugging webhooks. Instead of triggering the same event over and over, you can simply replay the request from the dashboard.

Best Practices for Development

Here’s a workflow that works well:

1. Use localhost for regular development It is faster and does not require any setup.

2. Switch to ngrok when you need external access Webhook testing, sharing with others, or testing on mobile devices.

3. Keep the ngrok inspector open — The localhost:4040 dashboard helps you understand exactly what is hitting your server.

4. Remember to update webhook URLs Since free tier URLs change, make it part of your routine to update any webhook configurations when you start a new ngrok session.

Conclusion

ngrok bridges the gap between local development and the real world. While localhost remains your go-to for everyday coding, ngrok is the tool you reach for when you need your local server to interact with the outside world. Whether it is testing webhooks, sharing progress, or ensuring your CORS configuration works correctly, ngrok makes these tasks simple.

Run ngrok http 5000 and see your local app go global in seconds.

A Visitor from Beyond

On July 1, 2025, humanity detected something extraordinary: 3I/ATLAS, the third confirmed interstellar object to pass through our Solar System. This is not just another interstellar oobject, it is a real cosmic traveler from the depths of space of our galaxy.

When we heard about this discovery, we knew we had to build something special: a real-time analytics dashboard that would make astronomical data accessible to everyone, from professional astronomers to curious students around the world.

What started as a weekend prototype evolved into a comprehensive web platform featuring interactive visualizations, real-time tracking, and support for four languages (English, Spanish, Chinese Mandarin, and Russian). The interesting part is that most of the development was done using Claude Code, Anthropic’s AI-powered development assistant.

The Technology Stack: Modern Web Meets Space Science

Before diving into the story, here is what powers the site:

┌─────────────────────────────────────────────────────────────┐
│                     USER INTERFACE LAYER                    │
│  HTML5 • CSS3 (16 Modular Files) • JavaScript (13 Modules)  │
└────────────────────────┬────────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
        ▼                ▼                ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  Highcharts  │  │    D3.js     │  │  Custom JS   │
│  (Charts &   │  │  (2D Solar   │  │  (Real-time  │
│   Gauges)    │  │   System)    │  │ Calculations)│
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────┐
│                      DATA LAYER                             │
│  ┌─────────────┐  ┌──────────────┐  ┌─────────────────┐     │
│  │ JPL Horizons│  │  Translations│  │  localStorage   │     │
│  │    API      │  │  (255+ keys) │  │  (User Prefs)   │     │
│  │ (NASA Data) │  │  (4 langs)   │  │  (Theme/Units)  │     │
│  └─────────────┘  └──────────────┘  └─────────────────┘     │
└─────────────────────────────────────────────────────────────┘

Core Technologies:

• Frontend: Vanilla JavaScript (ES6+), HTML5, CSS3
• Visualization: Highcharts (charts/gauges), D3.js v7 (solar system)
• Data Source: NASA JPL Horizons System
• Development: Claude Code (AI-assisted)
• Deployment: GitHub Pages

Part 1: The Prototype

Every ambitious project starts with a basic prototype. Ours was simple:

• Basic HTML page with static information about 3I/ATLAS
• A few Highcharts showing distance and trajectory
• Dark theme (because astronomy websites must be dark)
• Hardcoded data points copied from JPL Horizons

The prototype worked, but it was static, limited, and very much English-only. We knew we could do better…

Part 2: Enter Claude Code

This is where things get interesting. Instead of manually coding every feature, we partnered with Claude Code to accelerate development. Here is how the collaboration worked:

What Claude Code Did:

• Generated modular JavaScript architecture (13 focused modules)
• Implemented complex orbital mechanics calculations
• Created responsive CSS layouts (16 modular stylesheets)
• Built internationalization system with URL-based routing
• Wrote Schema.org structured data for SEO
• Refactored 2,584 lines of monolithic code into maintainable modules

What Humans Did:

• Strategic decisions (which features to prioritize)
• Design aesthetic and user experience
• Content creation and educational descriptions
• Quality control and cross-browser testing
• Data validation against NASA references
• Performance optimization decisions
• Minor code updates

The Rapid Iteration Experiment:

This project served as an experiment in AI-assisted development workflows. The traditional development cycle of prototype → test → refine → deploy typically takes weeks or months. With Claude Code, we compressed this into days:

1. Quick Prototyping: Generate initial features in minutes, not hours
2. Immediate Testing: Deploy, break things, learn what works
3. Rapid Iteration: Refactor, optimize, and add features based on real feedback
4. Continuous Deployment: Push updates multiple times per day

This rapid iteration cycle allowed us to experiment with features we might never have attempted in a traditional waterfall approach. For example, implementing hyperbolic orbit calculations or building a complete internationalization system would normally require extensive planning. Instead, we could prototype, test with real users, gather analytics data, and iterate. This was accomplished within the same week.

The Analytics Dashboard: Highcharts + Physics

One of the most challenging aspects was creating scientifically accurate visualizations. It is not just showing pretty graphs, every data point is calculated using real orbital mechanics.

Velocity Evolution Chart:

// Vis-viva equation: v = sqrt(GM × (2/r + 1/|a|))
const GM = 1.32712440018e20; // Sun's gravitational parameter
const a = -0.264 * AU_TO_METERS; // Semi-major axis (negative for hyperbolic)
const velocity = Math.sqrt(GM * (2/r - 1/a));

Solar Radiation Intensity:

// Inverse square law: F = L_sun / (4π × r²)
const L_sun = 3.828e26; // watts
const intensity = L_sun / (4 * Math.PI * r * r);

Why Highcharts?

We evaluated several charting libraries and chose Highcharts because:

• Precision: Supports scientific notation and high decimal precision
• Interactivity: Built-in zoom, pan, crosshairs, and responsive tooltips
• Performance: Smoothly renders thousands of data points
• Accessibility: Keyboard navigation and screen reader support
• Gauge Charts: Perfect for real-time metrics (distance, velocity, magnitude)

The result: 17 interactive visualizations that would take months to build from scratch, ready in days.

The Solar System Visualization: D3.js Magic

The crown jewel of the project is the interactive 2D solar system visualization. This required solving some serious computational geometry:

┌────────────────────────────────────────────────────────┐
│         ORBITAL MECHANICS PIPELINE                     │
└────────────────────────────────────────────────────────┘

    JPL Orbital Elements
         │
         ├─ Eccentricity (e): 6.137 (hyperbolic!)
         ├─ Perihelion (q): 1.356 AU
         ├─ Inclination (i): 175.11° (retrograde)
         ├─ Argument of Periapsis (ω): 128.01°
         └─ Longitude of Ascending Node (Ω): 322.15°
         │
         ▼
    Kepler's Equation (Hyperbolic)
         │  M = e×sinh(H) - H
         │  (Newton-Raphson iteration: 10 passes)
         ▼
    True Anomaly (ν)
         │  tan(ν/2) = √((e+1)/(e-1)) × tanh(H/2)
         ▼
    3D Cartesian Coordinates
         │  x, y, z in heliocentric frame
         ▼
    Rotation Transformations
         │  1) Rotate by ω (perihelion)
         │  2) Rotate by i (inclination)
         │  3) Rotate by Ω (ascending node)
         ▼
    2D Projection (Ecliptic Plane)
         │  Project 3D → 2D for visualization
         ▼
    D3.js SVG Rendering
         │  Smooth animations @ 50ms intervals
         ▼
    Interactive Visualization
         └─ Play/Pause, Speed Control, Date Slider

Key Challenge: Hyperbolic orbits are tricky. Unlike elliptical orbits (planets, typical comets), hyperbolic orbits use hyperbolic sine and tangent functions. We had to implement a Newton-Raphson solver to find the eccentric anomaly:

function solveHyperbolicKeplersEquation(M, e) {
  let H = M; // Initial guess
  for (let i = 0; i < 10; i++) {
    const f = e * Math.sinh(H) - H - M;
    const df = e * Math.cosh(H) - 1;
    H = H - f / df; // Newton-Raphson step
  }
  return H;
}

The result: a simple animation showing 3I/ATLAS’s trajectory from July 2025 through June 2026, with verified close approaches to Mars (0.223 AU) and Jupiter (0.265 AU).

Part 3: The Analytics Surprise

After launching the English version, we integrated Umami analytics (privacy-friendly, GDPR-compliant) and discovered something shocking:

Traffic Distribution (September 2025):

• China: 40% of traffic
• Russia: 35% of traffic
• USA: 14% of traffic
• Other: 11% of traffic

Search Engine Sources:

• Yandex (Russia): 51%
• Bing: 38%
• DuckDuckGo: 19%
• Google: 12%
• Baidu (China): Significant but hard to track

This was a wake-up call. 91% of our traffic came from non-English speaking regions, yet we only had an English site. It was time to internationalize.

Part 4: Data-Driven Translations

Most websites translate to Spanish, German, and French because those are “the usual suspects.” We took a different approach: translate to the languages our users actually speak.

Based on analytics:

1. Chinese (Simplified): 40% of traffic → Top priority
2. Russian: 35% of traffic → Second priority
3. Spanish: Global language → Third priority

We implemented full internationalization with 255+ translation keys per language:

// Translation system architecture
const translations = {
  en: {
    'mission.title': 'MISSION CONTROL DASHBOARD',
    'chart.velocity.title': 'Velocity Evolution',
    'countdown.perihelion': 'Closest to Sun'
    // ... 252 more keys
  },
  zh: {
    'mission.title': '任务控制仪表板',
    'chart.velocity.title': '速度演变',
    'countdown.perihelion': '最接近太阳'
    // ... 252 more keys (all translated)
  },
  ru: {
    'mission.title': 'ПАНЕЛЬ УПРАВЛЕНИЯ МИССИЕЙ',
    'chart.velocity.title': 'Эволюция скорости',
    'countdown.perihelion': 'Ближайшее прохождение Солнца'
    // ... 252 more keys
  }
}

Everything was translated:

• All chart titles, axes, and tooltips
• Mission Control dashboard
• Scientific data panels (6 modules)
• Gallery descriptions and metadata
• Navigation and UI elements
• Temperature labels (°C for Russia, °F option for US)
• Date formatting (3 октября 2025, 10月26日 2025, Oct 26, 2025)

URL Structure for SEO:

• English: /
• Spanish: /es/
• Chinese: zh/
• Russian: /ru/

Each URL is properly indexed with hreflang tags, ensuring international users find the right version in search results.

Part 5: The China Accessibility Challenge

Here is a problem most Western developers never think about: What if critical CDNs are blocked in your largest market?

China’s Great Firewall blocks:

• Google Fonts
• Many CDN providers
• Some JavaScript libraries

For Chinese users, our site was either broken or incredibly slow (30+ second timeouts). The solution:

Self-Host Everything Critical:

Before (External Dependencies):
- Google Fonts CDN (blocked in China) → 30s timeout
- Highcharts CDN (sometimes rate-limited) → Unreliable
- D3.js CDN → Blocked sporadically
Total load time in China: 35-45 seconds ❌

After (Self-Hosted):
- Space Grotesk fonts (local) → Instant
- Highcharts (local) → Instant
- D3.js (local) → Instant
Total load time in China: ~1.2 seconds ✅

We self-hosted:

• 5 font weights of Space Grotesk (340KB)
• Highcharts library (272KB)
• D3.js v7 (273KB)
• Font Awesome icons (940KB)

Total: 1.8MB, but cached after first visit. The tradeoff was worth it: 2-5x faster loading for 40% of our users.

Part 6: Optimizing for AI Search Engines

By late 2025, ChatGPT, Claude, and Perplexity were becoming primary research tools. We needed to optimize for AI-powered search.

Traditional SEO vs AI SEO:

AI-Specific Optimizations We Implemented:

1) Breadcrumb Schema: Helps AI understand site structure

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "URL" },
    { "@type": "ListItem", "position": 2, "name": "Analytics", "item": "URL" },
    { "@type": "ListItem", "position": 3, "name": "Live Tracking", "item": "URL" }
  ]
}

2) Citation Schema: Tells AI how to credit our data

{
  "@type": "CreativeWork",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "creditText": "Data sourced from NASA JPL Horizons System, ESA, and Minor Planet Center. Licensed under CC BY 4.0."
}

3) Speakable Content: Optimized for voice AI (ChatGPT voice mode, Alexa, Siri)

<div class="speakable">
  3I/ATLAS is the third confirmed interstellar object
  discovered on July 1, 2025. It will reach perihelion
  at 1.356 AU on October 29, 2025, traveling at 58 km/s.
</div>

4) Dataset Schema: Signals real-time, authoritative data

{
  "@type": "Dataset",
  "name": "3I/ATLAS Real-Time Tracking Data",
  "description": "Live orbital data updated every 5 minutes from NASA JPL Horizons",
  "temporalCoverage": "2025-07-01/..",
  "variableMeasured": [
    { "name": "Heliocentric Distance", "unitText": "AU" },
    { "name": "Velocity", "unitText": "km/s" },
    { "name": "Visual Magnitude", "unitText": "mag" }
  ]
}

Expected Impact: +50-200% traffic from AI search engines, better AI-generated responses about 3I/ATLAS.

The Architecture: From Monolith to Modules

Early in development, we had two giant files:

• script.js: 2,584 lines
• styles.css: 2,329 lines

Debugging was a nightmare. Making changes risked breaking everything. We needed modularization.

JavaScript Refactoring:

Before:                    After:
script.js (2,584 lines)    js/
                          ├── core/
                          │   ├── translations.js
                          │   ├── theme.js
                          │   └── navigation.js
                          ├── components/
                          │   ├── charts.js
                          │   ├── solar-system.js
                          │   ├── countdowns.js
                          │   └── realtime-data.js
                          ├── utils/
                          │   ├── orbital-calculations.js
                          │   ├── date-formatter.js
                          │   ├── error-handler.js
                          │   └── lazy-load-charts.js
                          └── app.js (entry point)

CSS Refactoring:

Before:                    After:
styles.css (2,329 lines)   css/
                          ├── base/
                          │   ├── variables.css
                          │   ├── reset.css
                          │   └── typography.css
                          ├── layout/
                          │   ├── header.css
                          │   ├── navigation.css
                          │   └── footer.css
                          ├── components/
                          │   ├── charts.css
                          │   ├── cards.css
                          │   ├── mission-control.css
                          │   └── solar-system.css
                          └── utilities/
                              ├── responsive.css
                              └── print.css

Result: 29 focused modules (13 JS + 16 CSS), average 200-300 lines each. Much easier to maintain, test, and extend.

Claude Code helped tremendously here, refactoring thousands of lines while maintaining zero visual changes.

Performance Optimization: Making it Fast

A beautiful site is useless if it is slow… We implemented aggressive optimizations:

Lazy Loading Charts (Intersection Observer):

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      initChart(entry.target.id); // Only load when visible
      observer.unobserve(entry.target);
    }
  });
}, { rootMargin: '50px' }); // Load 50px before visible

Result: 50% reduction in initial page load time (from ~2s to ~1s).

Service Worker for Offline Support:

// Cache-first strategy for static assets
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

Result: Instant repeat visits, works offline.

Critical CSS Extraction:

<!-- Inline critical CSS (~2KB) for instant render -->
<style>
  :root { --primary-color: #0a0a0a; }
  .hero { display: flex; }
  /* ... essential above-fold styles ... */
</style>

<!-- Defer non-critical CSS -->
<link rel="stylesheet" href="/css/main.css" media="print"
      onload="this.media='all'">

Final Performance Metrics:

• First Contentful Paint: ~0.8s
• Time to Interactive: ~1.2s
• Lighthouse Score: 95 (Performance, Accessibility, Best Practices, SEO)
• Bundle Size: 100KB (minified CSS/JS)

Key Features Worth Highlighting

Mission Control Dashboard: NASA-inspired real-time tracking

• Real-time distance from Sun, Earth, Mars, Jupiter
• Journey progress bar through solar system
• Next milestone countdown (orange highlight)
• Live data indicators (pulsing green dots)
• Updates every second for smooth animations

Scientific Data Panels: 6 comprehensive modules for researchers

• Orbital Metrics: Heliocentric distance (6-decimal precision), velocity, orbital elements
• Observability: Magnitude, solar elongation, rise/set times, constellation
• Physical Properties: Temperature, gas production rates, coma diameter
• Observation Quality: Position uncertainty, data arc, signal-to-noise ratio
• Environmental Context: Solar wind, zodiacal light, planetary distances
• Mission Planning: Next milestone, observation windows, equipment recommendations

All panels export JSON/CSV for data scientists.

Interactive Solar System (D3.js): Watch the interstellar object’s journey

• Play/Pause animation with 1x/5x/10x speed
• Date slider (July 2025 - June 2026)
• Real-time position and distance displays
• Accurate planetary positions from JPL Horizons
• Verified close approaches (Mars: 0.223 AU, Jupiter: 0.265 AU)

Challenges We Solved

Challenge 1: Hyperbolic Orbit Math

• Problem: Most orbit calculators assume elliptical orbits
• Solution: Implemented hyperbolic Kepler equation solver with Newton-Raphson
• Verification: Positions accurate to within 0.01 AU vs JPL data

Challenge 2: Real-Time Updates

• Problem: Cannot hit JPL API every second (rate limits)
• Solution: Calculate positions client-side using cached orbital elements
• Result: Smooth 1-second updates with zero API calls

Challenge 3: Multi-Language Chart Localization

• Problem: Highcharts does not auto-translate tooltips/axes
• Solution: Dynamic language configuration with month name arrays
• Example: “days until perihelion” → “距近日点天数” (Chinese)

Challenge 4: Mobile Responsiveness

• Problem: Complex charts and controls do not fit small screens
• Solution: Hamburger menu, collapsible panels, reduced chart heights
• Result: Fully functional on 320px phone screens

What We Learned

1) AI-Assisted Development Enables Rapid Experimentation

• Claude Code accelerated development by an estimated 3-5x
• The prototype → test → iterate cycle went from weeks to days
• Perfect for exploring ideas that would be too risky in traditional development
• Best for boilerplate, refactoring, and implementing known patterns
• Still requires human judgment for architecture and strategy
• Ideal for projects where speed to market and learning trumps perfection

2) Analytics Should Drive Decisions, Not Assumptions

• We would have translated to French/German (wrong)
• Data showed us Chinese/Russian were critical (right)
• 91% of traffic validated our translation strategy

3) Self-Hosting Matters for Global Reach

• CDN dependencies can break for entire countries
• Self-hosting adds size but guarantees reliability
• For 40% China traffic, the tradeoff was obvious

4) SEO is Multi-Dimensional in 2025

• Traditional search engines (Google) still matter, but…
• Regional engines (Yandex, Baidu, Naver) dominate their markets
• AI search engines (ChatGPT, Claude, Perplexity) are rising fast
• Each requires different optimization strategies

5) Modular Architecture Pays Long-Term Dividends

• 2,500-line files are technical debt
• 200-line focused modules are maintainable
• Refactoring hurts short-term, helps long-term

Acknowledgments

Building the site would have not been possible without:

• NASA JPL Horizons System: For comprehensive, authoritative orbital data
• ESA: For Mars orbiter observations and stunning imagery
• ATLAS Telescope Team: For discovering this rare interstellar visitor
• Highcharts: For excellent, scientific-grade visualization library
• D3.js: For powerful, flexible data visualization
• Anthropic: For Claude Code, our AI development partner
• Open Source Community: For the tools and libraries that power the modern web

Conclusion

We started with a prototype to track an interstellar object. Today, we have a comprehensive platform serving thousands of visitors across many countries, available in 4 languages, optimized for both traditional and AI search engines.

This is an ongoing project. As 3I/ATLAS continues its journey through our solar system and beyond, we are continuously adding new features, improving performance, and expanding our scientific data panels. The interstellar object will not reach its farthest observable point until mid-2026, giving us plenty of time to enhance the platform and serve the global community of astronomy enthusiasts.

And it all happened because we asked: What if we could make space science accessible to everyone?

The Challenge of Brand Asset Generation

Creating consistent, high-quality marketing assets is time-consuming and expensive. Designers spend hours creating social media graphics, marketing banners, and brand illustrations that align with brand guidelines. What if AI could automate this process while maintaining brand consistency?

Introducing Brandana

Brandana is an AI-powered platform built during the Nanobanana hackathon that automates the generation of marketing assets. By combining brand analysis with cutting-edge AI image generation, Brandana transforms brand inputs into production-ready visual assets.

Think of it as having an AI design assistant that understands your brand identity and creates custom graphics on demand.

The Technology Stack

Brandana leverages two powerful AI technologies to deliver intelligent asset generation:

1) Google Gemini for Brand Analysis

The Gemini API analyzes brand inputs and creates optimized prompts for image generation:

• Brand understanding: Processes brand guidelines, color schemes, and style preferences
• Prompt engineering: Generates detailed, context-aware prompts optimized for visual consistency
• Style translation: Converts brand requirements into AI-friendly descriptions

2) FAL.ai for Image Generation

FAL (Fast AI Labs) powers the actual image creation:

• High-quality generation: Creates production-ready marketing assets
• Fast processing: Optimized for speed without sacrificing quality
• Flexible output: Supports various aspect ratios and image formats

Architecture Overview

The platform follows a clean, pipeline-based architecture:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Brand Input    │───▶│  Gemini Prompt   │───▶│   FAL Image     │
│  (Guidelines)   │    │   Generator      │    │   Generation    │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                              │                         │
                              ▼                         ▼
                       ┌──────────────┐        ┌──────────────┐
                       │  Optimized   │        │  Generated   │
                       │   Prompts    │        │    Assets    │
                       └──────────────┘        └──────────────┘

Core Components:

Brand Input Layer

• Accepts brand guidelines, style preferences, and asset requirements
• Processes color palettes, typography rules, and visual identity
• Defines output specifications (dimensions, format, use case)

Prompt Generation Engine (Gemini)

• Analyzes brand characteristics and asset requirements
• Constructs detailed, optimized prompts for image generation
• Ensures consistency with brand identity
• Adapts prompts based on asset type (social media, banner, illustration)

Image Generation Pipeline (FAL)

• Receives optimized prompts from Gemini
• Generates high-quality visual assets
• Applies brand-specific styling and constraints
• Outputs production-ready images

Asset Management

• Stores generated assets with metadata
• Tracks generation parameters for reproducibility
• Enables batch processing and variation generation

The Workflow

Step 1: Brand Analysis

Users provide brand information:

• Brand guidelines and visual identity documents
• Color schemes and typography preferences
• Style references and mood boards
• Target asset types (social posts, banners, illustrations)

Step 2: Intelligent Prompt Generation

Gemini processes the brand input:

• Analyzes brand characteristics and visual language
• Identifies key styling elements and constraints
• Generates optimized prompts that capture brand essence
• Tailors prompts for specific asset requirements

Step 3: Asset Generation

FAL creates the visual assets:

• Processes Gemini-generated prompts
• Applies brand-specific styling
• Generates multiple variations if needed
• Outputs high-resolution, production-ready images

Step 4: Delivery

Generated assets are ready to use:

• Download in various formats and sizes
• Maintain consistency across asset types
• Iterate quickly with new variations
• Scale asset production efficiently

Results: Production-Ready Assets

Brandana generates three primary types of marketing assets:

Social Media Graphics

• Platform-optimized dimensions (Instagram, Twitter, LinkedIn)
• Brand-consistent color schemes and typography
• Engaging visuals that match brand identity
• Ready for immediate posting

Marketing Banners

• Web and display advertising formats
• Attention-grabbing designs aligned with brand
• Multiple size variations from single input
• Professional quality suitable for campaigns

Brand Illustrations

• Custom illustrations matching brand style
• Scalable vector-style outputs
• Unique visuals that reinforce brand identity
• Versatile assets for various marketing needs

The Nanobanana Hackathon Experience

Building Brandana during the hackathon showcased the power of combining specialized AI services:

Key Learnings:

• API orchestration: Successfully chained Gemini and FAL APIs for intelligent workflows
• Prompt engineering: Learned how AI-generated prompts can improve image quality
• Brand consistency: Discovered techniques for maintaining visual consistency across generated assets
• Rapid prototyping: Built a functional pipeline in hackathon timeframe

Technical Achievements:

• Integrated two different AI platforms seamlessly
• Created a reproducible asset generation pipeline
• Achieved brand-consistent outputs across asset types
• Demonstrated practical AI application for marketing

Use Cases

Marketing Teams

• Campaign assets: Generate complete asset sets for campaigns
• Social media content: Create consistent social graphics at scale
• A/B testing: Quickly produce variations for testing
• Event marketing: Rapid asset creation for time-sensitive events

Startups and Small Businesses

• Cost-effective design: Generate professional assets without design team
• Brand consistency: Maintain visual identity across channels
• Speed to market: Launch campaigns faster with automated asset creation
• Scaling visual content: Grow content production as business scales

Agencies

• Client assets: Produce initial concepts and variations quickly
• Pitches and proposals: Create mockups for client presentations
• Production efficiency: Augment design team output
• Rapid iteration: Test multiple creative directions efficiently

Future Directions

The Brandana prototype demonstrates significant potential for expansion:

Enhanced Brand Learning

• Train custom models on specific brand assets
• Build brand-specific style profiles
• Improve consistency through fine-tuning

Expanded Asset Types

• Video thumbnails and motion graphics
• Email marketing templates
• Presentation slide designs
• Print materials and packaging

Workflow Integration

• Direct integration with design tools (Figma, Canva)
• Publishing to social media platforms
• Asset management and versioning
• Team collaboration features

Advanced Customization

• Manual prompt refinement options
• Style transfer from reference images
• Multi-language support for global brands
• Custom model training for enterprise clients

The Future of Brand Asset Creation

Brandana represents a shift in how brands can approach visual content creation. By combining brand intelligence (Gemini) with generative capabilities (FAL), we can automate repetitive design work while maintaining the creative consistency that brands require.

The hackathon proved that AI-powered asset generation is not just possible, it is practical, fast, and capable of producing production-quality results.

Credits: Built during the Nanobanana Hackathon. Powered by Google Gemini and FAL.ai

The Problem with Always-On AI

Most AI development tools operate like an endless conversation—you can chat with them 24/7, burning through tokens and credits with every interaction. This leads to unpredictable costs, unfocused work sessions, and a lot of expensive trial-and-error. What if there was a better way?

Introducing the Night Shift Developer

NightAgents changes the script on AI-assisted development. Instead of always-on access, you get a dedicated AI co-worker that operates during one specific 8-hour window (or less than 8 hours depending on your choice): while you sleep.

Think of it as hiring a junior developer in the perfect timezone. They work the night shift, you review their work in the morning, and the cycle repeats until the works gets done.

How It Works

1) The Evening Handoff

Before bed, you brief your NightAgent like you would any co-worker:

• Define the scope: “Tonight, refactor the authentication module and add unit tests”
• Provide context: Share relevant files, documentation, or background
• Set priorities: What’s most important if time runs short?
• Establish constraints: API limits, coding standards, architectural decisions

2) The Night Shift (8 Hours Max)

While you sleep, your NightAgent:

• Analyzes your codebase and requirements
• Writes code, creates pull requests, and generates documentation
• Runs tests and performs code analysis
• Researches solutions and explores implementation options
• Logs all decisions and progress for your review

3) The Morning Review

Wake up to completed work waiting for you:

• Review pull requests with detailed explanations of changes
• Test implementations in your development environment
• Provide feedback on code quality, approach, or direction
• Plan the next night’s work based on progress and priorities

The Value Proposition

Predictable Costs

• Fixed 8-hour window prevents runaway token consumption
• Transparent pricing with no surprise bills
• Budget-friendly operation during off-peak hours

Intentional Development

• Constraint breeds focus: Limited time forces clear task definition
• Better planning: You must think through requirements before handoff
• Quality over quantity: Emphasis on completing well-defined tasks

True Productivity Gains

• Sleep becomes productive time: Your downtime becomes development time
• Continuous progress: Work happens even when you are offline
• Reduced context switching: Deep, focused work without interruptions

Sustainable Workflow

• Async by design: No need to babysit the AI during execution
• Human oversight: You maintain control over quality and direction
• Realistic expectations: Positioned as a junior developer, not a replacement

Implementation Strategy

Phase 1: Core Infrastructure

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   Task Queue    │───▶│   Night Agent    │───▶│  Output Store   │
│   Management    │    │   Orchestrator   │    │   (PRs, Docs)   │
└─────────────────┘    └──────────────────┘    └─────────────────┘

Essential Components:

• Task scheduling system with configurable night windows
• Token/credit management with hard limits and monitoring
• Code repository integration: (GitHub or GitLab)
• Secure sandbox environment for code execution and testing

Phase 2: Agent Capabilities

• Code generation and refactoring
• Test suite creation and maintenance
• Documentation writing and updates
• Performance analysis and optimization
• Dependency management and security scanning

Phase 3: Workflow Integration

• Morning dashboard with progress summaries and review queues
• Feedback mechanisms for continuous agent improvement
• Integration with existing development tools (IDEs, project management)
• Team collaboration features for shared night agent resources

Technical Architecture

Core Components

1) Task Orchestrator

• Manages the 8-hour execution window
• Prioritizes tasks based on user input
• Monitors resource consumption and enforces limits

2) Code Analysis Engine

• Understands existing codebase structure
• Identifies patterns and architectural decisions
• Generates context-aware solutions

3) Review Generator

• Creates detailed pull request descriptions
• Documents decision-making process
• Provides testing recommendations

4) Progress Tracker

• Logs all activities and decisions
• Tracks time allocation across tasks
• Generates morning summary reports

Use Cases

Individual Developers

• Side project acceleration: Make progress on personal projects while sleeping
• Learning and exploration: Research new technologies or frameworks overnight
• Technical debt cleanup: Tackle refactoring and maintenance tasks

Development Teams

• Continuous integration: Automated testing and quality checks
• Documentation maintenance: Keep docs current with code changes
• Cross-timezone collaboration: Bridge time gaps between distributed teams

Agencies and Consultancies

• Client work efficiency: More billable output without extended hours
• Proof-of-concept development: Rapid prototyping and iteration
• Maintenance contracts: Automated upkeep for client codebases

Getting Started

1) Define Your Night Window
Choose your optimal 8-hour window based on:

• Your sleep schedule
• Time zone considerations
• Development workflow preferences

2) Start Small Begin with well-defined, isolated tasks:

• Bug fixes with clear reproduction steps
• Unit test creation for existing functions
• Code formatting and linting cleanup

3) Establish Review Patterns
Create consistent morning routines:

• Check the progress dashboard
• Review and test generated code
• Provide feedback for continuous improvement
• Plan the next night’s work

4) Scale Gradually
As you build trust and refine processes:

• Tackle larger, more complex features
• Integrate multiple related tasks
• Customize agent behavior for your codebase

The Future of Development

The concept of “NightAgents” represents a shift from always-on AI assistance to intentional, constraint-based collaboration. By limiting when AI can work, we create space for:

• More thoughtful task planning
• Sustainable development practices
• Predictable costs and outcomes
• True human-AI collaboration

The night shift is not a limitation, it is an actual feature. It is the difference between having an AI tool and having an AI co-worker.

– Credits: NightAgents Logo was AI-generated by Chatgpt