DEV Community: Agastya Khati

[Boost]

Agastya Khati — Mon, 07 Sep 2026 06:59:45 +0000

DEV Weekend Challenge: Generosity Edition Submission 💜

Agastya Khati

Sep 7

Funded: Making Room for Education Through Generosity

#devchallenge #weekendchallenge

4 min read

Funded: Making Room for Education Through Generosity

Agastya Khati — Mon, 07 Sep 2026 06:59:33 +0000

This is a submission for Weekend Challenge: Generosity Edition)

What I Built

I built Funded, a student-focused crowdfunding platform designed around generosity in education.

Students can create fundraisers for tuition, books, housing, technology, course access, and other learning costs. Donors can discover real student stories, listen to an AI-generated audio introduction, and preview donation options.

My goal was to make asking for educational support feel more human, transparent, and accessible. Funded helps students turn a few honest notes into a respectful campaign story, while giving donors clearer ways to understand who they are helping and why.

Demo

The demo shows the complete Funded experience:

Discovering live student fundraisers
Creating a campaign with the Gemini Story Coach
Publishing the fundraiser instantly to the live feed
Listening to an ElevenLabs-generated campaign narration
Previewing a Dodo Payments checkout flow without making a real payment
Donating through Phantom using Solana Devnet, with an on-chain transaction receipt

Code

https://github.com/kris70lesgo/funded

How I Built It

Funded is a React and TypeScript web application with a custom frontend focused on a calm, editorial crowdfunding experience. The interface uses a clean layout, warm student imagery, clear campaign cards, and simple donation flows so the product feels trustworthy rather than overwhelming.

Campaign creation and publishing

The fundraiser creation flow collects the information a donor actually needs to understand a request:

Fundraiser title
Education category
Funding goal
Student name
Cover image
Personal story
Fundraiser updates

Once a campaign is submitted, it is stored in Supabase and receives a unique slug-based URL. The application then redirects the student to their live fundraiser page. The campaign is also available in the Discover feed so other users can find it immediately.

Campaign owners can delete their own fundraiser through an in-app confirmation interface. This was important because students should remain in control of the campaigns and stories they publish.

Supabase

Supabase is used for authentication and campaign data storage.

The application supports normal email and password sign-up and sign-in. After a user signs in, the interface updates to show their account state instead of showing the Sign in action.

Fundraiser records are stored in Supabase, including the title, category, story, funding goal, creator details, campaign progress, image, and publication date. The Discover page retrieves these campaigns so the public feed reflects newly published fundraisers instead of only showing static content.

I also added sample fundraiser data to Supabase so the demo has realistic student campaigns available immediately. This helps demonstrate the complete donor experience from the first visit.

Google Gemini: Story Coach

One of the biggest barriers for students is knowing how to write a fundraiser story. Students may have a real need and a strong goal, but still struggle to explain it in a way that is clear, respectful, and comfortable to share.

The Gemini Story Coach solves this by taking a few student-provided notes, such as:

What they are studying
What they need funding for
Their achievements or current situation
Their future goals
Why this support matters now

Gemini then helps create a well-structured campaign story. The output is designed to be supportive and concise, not exaggerated or manipulative. The student can always edit the story before publishing, keeping their own voice and control over the final fundraiser.

ElevenLabs: Audio campaign stories

Every fundraiser has the option to include an AI-generated audio narration powered by ElevenLabs.

The narration turns the campaign story into a spoken introduction that donors can play directly on the fundraiser page. This adds an emotional and accessible layer to the platform. Instead of only reading a block of text, a donor can listen to the student’s goals and reason for fundraising.

This feature is useful for accessibility, mobile users, and donors who connect more strongly with a spoken story. It also makes each fundraiser page feel more personal without requiring students to record their own audio.

Solana and Phantom

Funded supports a Solana donation flow through Phantom.

For the hackathon demo, the integration uses Solana Devnet. When a donor chooses to contribute with SOL, the application prepares the transaction and asks the donor to approve it in their Phantom wallet. Funded never receives or stores wallet private keys.

After approval, the transaction can be referenced as an on-chain receipt. This creates a transparent record of the contribution and demonstrates how blockchain can support trust in crowdfunding.

Using Solana also helps show a future direction for Funded: transparent, low-friction support that can be verified publicly while still keeping the donor in control of their wallet.

Dodo Payments

Funded also includes a Dodo Payments checkout flow for donors who prefer a familiar checkout experience.

For this hackathon demo, the Dodo checkout is shown as a preview only. No real payment is intentionally completed. This lets the project demonstrate how a traditional payment flow would fit into the platform while keeping the demo safe and focused on the user journey.

Why these technologies matter together

Funded combines these technologies to address different parts of the generosity experience:

Supabase makes fundraisers persistent, live, and manageable.
Google Gemini helps students communicate their needs with confidence.
ElevenLabs gives fundraiser stories a more personal and accessible voice.
Solana provides transparent, wallet-controlled contributions with on-chain proof.
Dodo Payments provides a familiar checkout path for future real-world contributions.

Together, these tools help turn generosity into something that is easier to ask for, easier to understand, and easier to trust.

Prize Categories

Best Use of Solana — Funded integrates Phantom wallet donations on Solana Devnet. Donors approve transactions in their own wallet, and the resulting transaction can act as transparent, public proof of support.
Best Use of ElevenLabs — Funded generates playable audio narrations for fundraiser stories using ElevenLabs. This makes campaigns more personal and accessible for donors.
Best Use of Google AI — Funded uses Gemini as a Story Coach that helps students transform a few honest notes into a clear, respectful, and shareable fundraiser story while keeping the student in control of the final content.

Fruit Dash: A Solstice Platformer with Binary Code Gates

Agastya Khati — Sat, 20 Jun 2026 11:06:26 +0000

This is a submission for the June Solstice Game Jam

What I Built

I built Fruit Dash, a lightweight 2D browser platformer inspired by the bright, playful energy of June and the June Solstice.

Fruit Dash is a colorful pixel-art platformer where the player chooses a character, enters a 50-level world, collects fruit, avoids traps, fights enemies, activates checkpoints, and clears each stage by reaching the end flag.

The game includes:

50 generated platforming levels
Character selection
Level selector
Fruit collection
Jumping and double jumping
Fireball/powerball attacks
Enemies that scale by level
Checkpoints and end flags
Saws, spikes, fire traps, arrows, fans, trampolines, moving platforms, boxes, and surfaces
Background music with mute/unmute control
Mobile and tablet touch controls
Turing Gate binary puzzles on milestone levels

For the June Solstice theme, I wanted the game to feel like a bright seasonal arcade adventure: colorful, energetic, full of motion, and centered around progression. The solstice is a turning point in the year, and Fruit Dash mirrors that through the way each level moves the player forward into new hazards, enemies, and mechanics.

I also added a specific Alan Turing-inspired mechanic: Turing Gates. On milestone levels, the exit is locked behind a small binary code puzzle. The player must shoot three binary switches until the bits match the target code. This connects the platforming gameplay to computation, binary logic, code-breaking, and Turing’s legacy in computer science.

Video Demo

Code

GitHub repository:

kris70lesgo / fruitdash

Fruit Dash

Fruit Dash is a lightweight 2D browser platformer built for the June Solstice Game Jam. It is a colorful fruit-collecting platformer about movement, progression, and small moments of code-breaking.

The game runs directly in the browser with plain HTML, CSS, and JavaScript. No heavy game engine is required.

Play

Live demo:

https://game-jade-one-25.vercel.app

Local run:

python3 -m http.server 4173

Then open:

http://127.0.0.1:4173/game-src/index.html

Features

50 generated platforming levels
Home screen, level selector, and character selection
Fruit collection with multiple fruit types
Jumping, double jumping, checkpoints, and end flags
Tiered enemies: mushrooms, Vomfy, slimes, and mixed late-game waves
Fireball/powerball attack with character-specific colors
Traps and movement tools: saws, spikes, fire, arrows, fans, trampolines, moving platforms, boxes, and surfaces
Turing Gates on milestone levels with binary switch puzzles
Looping background music with mute/unmute control
Touch controls for mobile and tablet, including a fire button
Vercel-friendly root entry page

Controls

Move: A/D or…

View on GitHub

Live demo:

https://game-jade-one-25.vercel.app

How I Built It

Fruit Dash is built with plain HTML, CSS, and JavaScript. I intentionally avoided a heavy game engine so the game would stay lightweight, easy to deploy, and fully controllable in the browser.

The game runs on an HTML canvas. The player, enemies, fruits, traps, projectiles, platforms, checkpoints, Turing Gates, and HUD are all drawn and updated manually in JavaScript.

The visual style comes from pixel-art PNG assets and sprite sheets. The game uses sprites for characters, fruits, terrain, traps, enemies, fireballs, checkpoints, and UI elements.

The level system is generated in code. Each level creates a different combination of:

Ground platforms
Floating platforms
Fruits
Boxes
Checkpoints
End flags
Moving platforms
Hazards
Trampolines
Fans
Enemies
Turing Gates on milestone levels

Difficulty increases as the level number rises. Early levels focus on movement and collection. Later levels introduce more enemies, hazards, and tighter platforming situations.

Enemies are introduced by level tier:

Early levels use mushroom enemies
After level 10, Vomfy enemies appear
After level 30, slimes appear
After level 40, enemy types are mixed together

The player can shoot fireballs using Enter, mouse click, tap, or the mobile fire button. Fireballs use sprite-sheet animation and have character-specific colors. They disappear when they hit enemies, platforms, traps, switches, or other solid objects.

For the Turing-inspired mechanic, levels 10, 20, 30, 40, and 50 include Turing Gates. Each gate displays a 3-bit binary target. The player shoots three bit switches to toggle them between 0 and 1. When the current bit pattern matches the target, the exit unlocks.

I also added background music. The original audio file was an OGG file around 11 MB, which felt too large for a small browser game. I used FFmpeg to convert it into a smaller MP3 file, reducing it to around 4.1 MB and improving browser compatibility. The music loops after the first player interaction because browsers usually block autoplay audio until the user clicks, taps, or presses a key.

For mobile support, I added touch controls that appear automatically on touch screens. Mobile and tablet players can move, jump, and fire without a keyboard.

The game is deployed as a static site on Vercel. I also added a root index.html so the deployed URL opens correctly instead of returning a 404.

Challenges I Faced

One of the biggest challenges was making sure the collision system matched the visuals. At one point, some platforms had collision but were not visibly drawn because the wrong part of the terrain sprite sheet was being used. This made the character look like they were standing on invisible platforms. I fixed this by correcting the terrain tile coordinates and adding safer fallback drawing for platform types.

Generated level quality was another major challenge. Since levels are built in code, some objects were originally placed in awkward spots. Fruits could appear in cramped areas that were hard or impossible to reach. Fans could appear under platforms, pushing the player directly into a ceiling. I added a cleanup pass to the level generator that checks fruit placement, reduces overlapping fruit clusters, and only places fans where the upward air path is actually useful.

The arrow trap also needed redesign. Initially, touching an arrow restarted the player, which felt unfair and not very meaningful. I changed arrows into directional boosters so they become a movement mechanic instead of just another punishment.

Enemy sprite alignment was tricky too. Some enemy sprite sheets had transparent padding, so enemies looked like they were floating even when their collision boxes were touching the ground. I adjusted enemy drawing offsets so their feet visually line up with the platform.

Adding Turing Gates required balancing the puzzle with the platforming. I did not want to turn the whole game into a slow puzzle game, so I placed the binary gates only on milestone levels. That way the Alan Turing tribute appears clearly, but the main game still feels like an arcade platformer.

Audio also had browser-specific challenges. Modern browsers block autoplay audio, so the music starts after the first player interaction. I also added a mute/unmute button so the player has control.

Deployment had one final issue: Vercel initially showed a 404 because the actual game was inside game-src/index.html, not the project root. I fixed this by adding a root index.html that forwards to the game.

Prize Category

I am submitting for two prize categories:

Best Ode to Alan Turing

Fruit Dash includes a Turing-inspired mechanic called Turing Gates.

On milestone levels, the exit is locked behind a binary code puzzle. The game displays a 3-bit target code, and the player must shoot three binary switches until the switch values match the target.

This is an arcade-style tribute to Alan Turing’s legacy in computation, logic, code-breaking, and the foundations of modern computer science. I wanted the tribute to exist inside the gameplay itself, not only in the submission description.

The player solves a small binary logic problem, unlocks the gate, and continues the level.

Best Google AI Usage

Google AI helped throughout the development process. I used Antigravity IDE for development ,also while building and iterating on the game. It helped with code generation, debugging, gameplay iteration, layout fixes, and improving the structure of the app.

AI assistance was especially useful for:

Debugging invisible platform issues
Fixing sprite alignment problems
Improving generated level placement
Adding enemies and attacks
Adding mobile controls
Adding audio controls
Optimizing the background music file
Preparing the project for Vercel deployment
Shaping the Turing Gate binary puzzle mechanic

I also used Gemini models / Gemini API workflows during the creative process for asset and image-related experimentation. The final game is still a browser-based JavaScript game using local assets, but Google AI helped speed up the design, development, debugging, and iteration process.

Finishing HELIX: Building an AI-Powered Space Operations Intelligence Platform with GitHub Copilot

Agastya Khati — Fri, 05 Jun 2026 14:29:52 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

This is my submission for the GitHub Finish-Up-A-Thon Challenge.

The idea behind this challenge really hit home for me: finally finish what you started.
HELIX started as a satellite tracking and conjunction detection project. It already had a working backend, orbital propagation, a 3D globe, and basic AI summaries. But it still felt like a technical prototype.
For this challenge, I brought it much closer to a finished product.
I turned HELIX into an AI-powered space operations intelligence platform that can investigate orbital risk, correlate multiple space data sources, and generate explainable operational assessments.
GitHub Copilot helped me push the project from “cool prototype” to something that feels like a real mission operations console.

Demo

Github Repository :

kris70lesgo / helix

HELIX

Coral-Powered Space Operations Intelligence Platform

HELIX is an AI-powered Space Operations Intelligence Platform that transforms fragmented orbital, launch, and space weather data into actionable mission intelligence.

Built on top of Coral's federated SQL runtime, HELIX enables operators, researchers, and analysts to investigate conjunction risks, correlate launch activity, monitor orbital congestion, and generate explainable operational assessments through multi-step AI investigations.

Unlike traditional satellite trackers, HELIX focuses on answering:

What is happening in orbit?

Why is it happening?

What should operators pay attention to next?

Why HELIX?

Earth's orbit is becoming increasingly congested.

Thousands of active satellites, frequent launches, and growing debris populations create a complex operational environment where understanding risk requires data from multiple disconnected systems.

Most tools can visualize orbital activity.

HELIX investigates it.

Using Coral as a unified intelligence layer, HELIX correlates:

Satellite conjunction events
Launch schedules and mission activity
Space weather conditions
Satellite metadata
Historical orbital trends

…

View on GitHub

What HELIX Does

HELIX is a local-first space situational awareness and mission intelligence platform.

It helps answer questions like:

Why are conjunction risks elevated today?
Which satellites repeatedly appear in high-risk events?
Are upcoming launches contributing to orbital congestion?
Is space weather affecting operational risk?
What should an operator monitor next?

Instead of only showing satellite positions, HELIX performs structured investigations over operational data.

Core Features

3D Satellite Monitoring

HELIX includes a real-time globe interface for viewing satellites and conjunction events.

The frontend uses:

Next.js
React
TypeScript
Three.js
react-globe.gl

The backend uses:

FastAPI
SQLite
SGP4 orbital propagation
KD-tree optimized conjunction detection

System Architecture:

Multi-Source Operational Intelligence

HELIX connects multiple operational data sources:

Local satellite and conjunction database
NOAA space weather data
Launch Library launch data
Space-Track metadata

These sources are exposed through Coral as SQL-queryable tables.

That means HELIX can run cross-source intelligence queries like:

conjunction risk + NOAA space weather
launch activity + current solar conditions
closest conjunctions + Space-Track object metadata
Starlink launch activity + local conjunction pressure

Multi-Step AI Investigation Agent

The biggest finish-up improvement was moving from:
prompt → query → summary
to:
prompt → investigation plan → query chain → findings → assessment → recommendations

The investigation engine is deterministic and safe.
It does not generate arbitrary SQL.
Instead, it chooses from approved Coral SQL templates and runs a bounded sequence of investigation steps.

Example investigation:
`User: Why are conjunction risks elevated today?

[1] Querying conjunction risk distribution
[2] Analyzing closest high-risk events
[3] Detecting repeated satellite involvement
[4] Comparing risk density by day
[5] Checking upcoming launch activity
[6] Checking NOAA space weather
[7] Correlating findings
[8] Generating operational recommendations`

Before and After

When I started, HELIX was primarily a space visualization prototype.

The first version could display satellites on a 3D globe and visualize orbital tracks, but the overall product was still incomplete. The core visualization layer worked, but most of the operational intelligence layer was missing. The Intel experience and the Conjunctions workflow existed mostly as ideas and partially implemented components rather than finished features.

The early version included the basic foundation:

Satellite globe visualization
Object counts and statistics
Basic live status information
Planned Intel and Conjunctions navigation
Early conjunction detection data

While the foundation was solid, it did not yet feel like a complete operations platform. Users could observe activity in orbit, but they could not effectively investigate, analyze, or act on that information.

The Final Version

The final version of HELIX is much closer to a real mission-control-style interface.

It now includes:

A polished interactive satellite globe
Live satellite detail drawer
High-risk conjunction overlays
Conjunction count indicators and alert banners
Fully functional Intel console
Working Conjunctions panel
Operational investigation workflow
Coral-backed cross-source intelligence analysis
AI-generated operational recommendations

The current interface transforms the globe from a visualization component into an operational workspace.

Instead of simply displaying satellites, HELIX now surfaces:

Active high-risk conjunction events
Detailed satellite metadata
Live position and velocity information
Investigation context
Operational intelligence insights

The globe is no longer just showing data it is helping explain and investigate it.

How GitHub Copilot Helped

GitHub Copilot played a major role in turning unfinished concepts into working product features.

The most significant contributions were helping build the areas that previously existed only as plans:

The Intel console
The Conjunctions workflow
Backend intelligence endpoints
The multi-step investigation engine
Coral SQL query chaining
Frontend operational panels and UI states

More importantly, Copilot helped support the entire engineering workflow rather than simply generating isolated code snippets.

The process looked like this:

Inspect the existing codebase
Understand the backend and frontend architecture
Identify where missing features should integrate
Implement backend APIs
Connect frontend interfaces
Test the application
Resolve integration and debugging issues
Polish the final experience

Copilot was especially valuable for bridging the gap between planned functionality and working functionality.

Many parts of the interface already existed visually, but they were not fully connected to operational workflows. Copilot helped move the project from:

Button exists
→ Feature planned
→ Logic incomplete

to:

Button exists
→ Backend implemented
→ Frontend connected
→ Investigation workflow operational
→ Feature fully functional

Outcome

As a result, HELIX evolved from a satellite visualization prototype into a complete AI-powered space operations intelligence platform.

It now supports:

Operational investigations
Conjunction monitoring
Cross-source intelligence analysis
AI-assisted assessments
Coral-backed data correlation
Actionable operational recommendations

The project did not require a complete rebuild.

It required finishing the missing pieces, connecting existing systems together, and transforming concepts into working features.

GitHub Copilot helped make that transition possible.

The Comeback Story of HELIX

Before the Finish-Up-A-Thon, HELIX was a project with a lot of potential but it was stuck in the place where many ambitious side projects end up.

The foundation was already there.

It had a FastAPI backend, satellite data ingestion, orbital propagation, conjunction detection, a SQLite database, and a 3D globe interface. It could track satellites, visualize orbital activity, and identify close approaches between objects in space.

Technically, it worked.

But it didn't feel finished.

HELIX could tell users what was happening, but it struggled to explain why it was happening. The AI layer was limited to basic summaries, many features felt disconnected, and the overall experience resembled a collection of powerful components rather than a unified intelligence platform.

In short, HELIX felt more like a satellite-tracking prototype than a true mission operations system.

That was the state of the project when I began the finish-up process.

Enter GitHub Copilot

Instead of starting over, I focused on understanding what already existed.

Using GitHub Copilot and advanced GPT-5.5 style assistance, I began by inspecting the codebase, mapping the architecture, and identifying the areas that would create the biggest impact if improved.

The process became highly iterative:

Understand the existing system
Identify weak points
Plan improvements
Implement safely
Test thoroughly
Repeat

Rather than rewriting everything, I concentrated on strengthening what was already there.

Bringing HELIX Back to Life

The first step was cleaning up and stabilizing the architecture while preserving the satellite tracking and conjunction detection capabilities that already worked.

From there, I introduced Coral as the data orchestration layer and connected multiple operational datasets into a unified queryable system.

Suddenly, HELIX was no longer looking at isolated pieces of information.

It could correlate data across:

Conjunction events
Satellite metadata
Launch activity
NOAA space weather
Space-Track datasets

The project started evolving from a visualization tool into an intelligence platform.

The Biggest Transformation

The most significant change was the intelligence workflow itself.

Before, the AI interaction looked something like this:

Ask a question
→ Run a query
→ Summarize the results

It worked, but it was shallow.

The system answered questions without actually investigating them.

I wanted HELIX to think more like an analyst.

So I built a deterministic investigation engine that transformed the workflow into:

Ask a question
→ Build an investigation plan
→ Execute approved Coral queries
→ Correlate findings
→ Generate an assessment
→ Recommend next actions

With the help of Copilot, I implemented:

Multi-step investigation workflows
Query tracing and transparency
Passive monitoring alerts
Operational recommendations
Investigation timelines in the UI
Backend intelligence endpoints
Frontend investigation experiences

The system stopped behaving like a chatbot and started behaving like an operations analyst.

A Different Kind of Answer

Consider a question like:

Why are conjunction risks elevated today?

Previously, HELIX would have returned a simple summary of conjunction data.

Now it performs a full investigation.

It can:

Analyze conjunction density
Identify repeatedly involved satellites
Check recent launch activity
Review NOAA space weather conditions
Compare current activity with historical patterns
Correlate findings across multiple datasets

Only then does it generate an assessment and suggest possible operational actions.

That fundamentally changed how the platform feels.

From Prototype to Platform

The transformation wasn't about adding flashy features.

It was about connecting everything together.

GitHub Copilot helped accelerate the parts that often cause projects to stall:

Understanding a large codebase
Architecture planning
Safe refactoring
Backend development
Frontend improvements
SQL generation
API debugging
Documentation
Final validation

Feature by feature, HELIX became more cohesive, more intelligent, and more useful.

Where HELIX Stands Today

Before the Finish-Up-A-Thon, HELIX was a promising demonstration of satellite tracking technology.

Today, it feels like a genuine AI-powered space operations console.

It can investigate, correlate, explain, and recommend not just visualize.

The project didn't need a complete rewrite.

It needed someone to finish what had already been started.

GitHub Copilot helped make that possible.

And in many ways, HELIX's biggest achievement wasn't the technology itself—it was finally crossing the line from almost finished to fully realized.

My Experience with GitHub Copilot

How GitHub Copilot Helped

I used GitHub Copilot heavily throughout the finish-up process, specifically with advanced ChatGPT/GPT-5.5 style coding assistance.

Copilot helped with:

reading and understanding the existing codebase
planning the architecture
refactoring the project safely
adding the investigation engine
creating backend endpoints
improving the frontend UI
generating SQL query templates
debugging API issues
writing documentation
validating the final build

The most valuable part was not just code generation. It was the ability to work iteratively:

inspect the existing project
identify weak points
plan the next phase
implement safely
test
repeat

That workflow made it possible to finish a project that otherwise could have stayed half-done.

one of the best blogs about hermes agent

Agastya Khati — Sun, 31 May 2026 05:33:20 +0000

Hermes Agent Challenge Submission: Write About Hermes Agent

Paimon

May 31

Nous Research Hermes Agent: Setup and Tutorial Guide

#hermesagentchallenge #devchallenge #agents

10 min read

Credexia: AI-Powered Loan Compliance Built with Google Gemini

Agastya Khati — Wed, 04 Mar 2026 04:05:01 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

Building Credexia: How Gemini Became My 48-Hour Co-Founder

The Event

I built Credexia at the LMA Edge Hackathon, where the theme was loan market innovation. The challenge was to modernize how banks handle loan servicing after the trade is signed. While trading platforms have gone digital, post-closing operations are still stuck in Excel hell. I had 48 hours to change that.

The LMA ecosystem has tools for drafting loans and platforms for price discovery, but there is a massive white space in between. Banks can agree on trades and sign loans digitally, yet post-closing servicing and settlement remain fragmented. Excel sheets, endless email chains, manual data re-entry, broken reconciliation. Liquidity is not blocked by lack of capital. It is blocked by operational friction.

My goal was to build the Operating System for Loans. A unified platform connecting covenant monitoring, trade settlement, and cash distribution in real time.

What I Built

Credexia is a unified desktop platform covering three critical loan lifecycle stages in one dashboard. It is built on Next.js 16 with React 19, TypeScript 5.8, and styled with Tailwind CSS 4, MUI 7, and Framer Motion for animations.

Demo Video

See Credexia in action:

https://youtu.be/3GrR22gW9SU?si=aFDLldcB2vOJYxK8

Live Website

Try the platform:

https://credexia.vercel.app/

GitHub Repository

View the code:

kris70lesgo / Credexia

Credexia

A Next.js + Supabase + Ethers-powered platform for blockchain-verified loan covenant monitoring, OCR-driven data extraction, and portfolio analytics.

Features

AI-assisted chat for covenant guidance (Gemini)
OCR-backed document intake with fallback parsing
Covenant calculations (Debt/EBITDA, ICR, current ratio)
Polygon Amoy sealing for compliance events
Dashboard for loans, uploads, reports, and trade utilities

Stack

Next.js 16, TypeScript, Tailwind
Supabase (auth, DB, storage)
Ethers.js for Polygon interactions
Google Gemini for AI responses and parsing

Prerequisites

Node 18+ and npm
Supabase project with SUPABASE_URL and service key
Polygon Amoy RPC endpoint and funded deployer key
Gemini API key for AI features

Setup

Install deps: npm install
Copy .env.local.example to .env.local (if present) and set:

SUPABASE_URL=
SUPABASE_SERVICE_ROLE_KEY=
SUPABASE_ANON_KEY=
GEMINI_API_KEY=
POLYGON_RPC_URL=
BLOCKCHAIN_PRIVATE_KEY=
API_KEY=                  # optional API auth
ALLOWED_ORIGINS=*         # comma-separated list in prod

Run dev server: npm run dev
Optional: compile contracts: npx hardhat compile

Scripts

npm run dev – start Next.js dev server
npm…

View on GitHub

Monitoring

Tracks financial covenants like Debt/EBITDA and ESG covenants like Carbon Emissions. Users upload a PDF financial report. AI extracts values and calculates compliance. A traffic light system shows status: Green for Safe, Amber for Warning, Red for Breach. If an ESG covenant is breached, the interest rate automatically adjusts according to loan terms.

TradeClear

Digitizes the transfer of loan ownership. Users upload a Notice of Assignment PDF. AI extracts Seller, Buyer, and Trade Amount. After approval, the Ownership Register updates instantly. This removes manual ledger updates entirely.

AgentFlow

Automates the Payment Waterfall. It distributes borrower payments across lender banks, enforces zero rounding error, assigns any remainder to the Agent Bank, and generates SWIFT-ready CSV in seconds.

Global State

All three modules share a Global State. If ownership changes in TradeClear, AgentFlow instantly reflects the new owner without a page reload. This is managed through an in-memory global singleton with hot-reload safety, though this would need Redis or a database for true production multi-instance deployment.

How Gemini Powered Everything

I used Gemini at every layer of the stack. Not as a helper. As a co-builder. The AI layer centers on Google Gemini 2.5 Flash with a 4-tier fallback system: Gemini 2.5 Flash, Gemini 2.5 Pro, Gemini 1.5 Flash, and Gemini 1.5 Pro. OCR.space serves as a raw text backup when needed. A confidence gate at 60% ensures that if AI confidence drops below this threshold, the user must confirm before proceeding.

Document Understanding

The core feature is PDF ingestion. A credit analyst uploads Q4 financials. Gemini extracts the numbers, calculates ratios, and flags breaches. The extraction targets totalDebt and ebitda fields with confidence scoring. When confidence is low or parsing fails, an OCR fallback path activates.

The first extraction test I ran returned a Debt/EBITDA ratio of 47x. The real number was 4.7x. Gemini had misread a table cell. That single failure taught me why finance demands confidence gates and deterministic logic. I rebuilt the extraction layer with strict validation and the 60% confidence threshold.

Code Generation

I wrote maybe 40% of the React components myself. The rest came from Gemini prompts. The traffic light dashboard, the upload flow, the audit log interface. I would describe what I needed, iterate twice, and have production-ready code. The marketing landing page with animated hero, the login authentication flow, the portfolio dashboard with analytics cards, the loan tables, the document intake with OCR processing, the compliance reporting, the trade workflow UI, and the AI agent orchestration view all benefited from Gemini-generated code.

Blockchain Integration

I used Gemini to write the Solidity contracts for Polygon Amoy testnet. The CovenantRegistry.sol contract handles SHA-256 covenant sealing. Each compliance event gets a txHash for immutable audit trails. When I hit the "private key fiasco" at 3 AM, where my .env key had an extra character, Ethereum keys must be exactly 64 hex characters, Gemini debugged the error message with me. I also implemented a demo mode using FNV-1a hash simulation when the network fails, ensuring the demo never crashes regardless of API failure.

Trade Clearing Architecture

The trade module has 7 sub-routes forming a complete lifecycle: upload, parse, validate, owners, approve, confirm, and events. This supports partial ownership transfers between banks. The in-memory trade state singleton prevents loss during Next.js hot reload, though production would need a persistent store.

Payment Waterfall Precision

The waterfall distributes cash to syndicate members by ownership share. Floating-point remainder always assigns to Agent Bank to ensure exact totals. This handles fractional splits and guarantees perfect totals, solving the zero-variance requirement that took six hours to perfect. Not because the math is hard. Because financial systems demand perfection.

AI Chat Assistant

I built a covenant guidance chatbot powered by Gemini. It answers questions about loan covenants, risk analysis, debt-to-EBITDA calculations, document uploads, OCR extraction, blockchain verification, and portfolio insights.

The Pitch Deck

Yes, I even used Nano Banana, Gemini's image generation, for the pitch deck visuals. The LMA judges saw AI-generated diagrams explaining AI-powered compliance. Meta, but effective. Gemini helped structure the narrative and create visuals that made institutional infrastructure feel tangible.

Credexia_ Reinventing Trust, Transparency, and Automation in Loan Markets.pptx - Google Slides

docs.google.com

Technical Architecture

The frontend runs on Next.js 16 App Router with 18 API routes covering loans, chat, OCR, parsing, extraction, covenant calculations, blockchain sealing, compliance events, portfolio data, uploads, waterfalls, and the full trade lifecycle.

All business logic is implemented as pure functions with deterministic outputs. The covenant engine in particular has no side effects, calculating Debt/EBITDA ratios, Interest Coverage Ratios, and Current Ratios with strict mathematical precision.

Database and authentication use Supabase with Postgres and Storage. The blockchain layer uses Ethers.js 6 with Hardhat 3 for smart contract development. Smart contracts are written in Solidity and deployed to Polygon Amoy testnet.

What I Learned

AI Needs Guardrails

My first extraction failure taught me that finance cannot tolerate hallucination. The 47x versus 4.7x error led to the confidence gate system and deterministic validation layers. Every AI output gets verified before it touches a financial calculation.

Model Names Are Chaos

I spent two hours debugging 404 errors before realizing "gemini-2.5-flash" and "gemini-2.5-flash-preview" are different endpoints. The 4-tier fallback system was born from necessity, not planning. Incorrect model names caused API failures that required the retry logic I implemented.

Simulation Beats Broken Reality

OCR on messy financial tables failed constantly. Rather than fight it, I built demo-friendly PDFs with clean formatting and a manual override. The demo worked. The architecture was real. Resilient architecture means the app never crashes during demo regardless of API failure.

The Last Mile Is Process, Not Math

Getting the payment waterfall to sum to exactly 100% with no rounding errors took six hours. Not because the math is hard. Because financial systems require perfection. The operational friction in fintech is not about complex calculations. It is about ensuring those calculations are auditable, deterministic, and zero-error.

Schema Drift Happens Fast

Frontend expected fields that did not exist in Supabase. I adapted the frontend to the database rather than migrating the database mid-hackathon. This pragmatic approach preserved velocity when time was critical.

What Worked and What Didn't

What Worked

Speed. I prototyped a full-stack fintech platform in 48 hours because Gemini accelerated every decision. Multi-modal document understanding. The ability to throw a PDF at an API and get structured JSON back feels like magic when it works. The traffic light UI gave instant risk visibility across the portfolio. Honest error handling meant no silent failures. Users see real confidence and validation errors.

The Friction

Inconsistency. Same prompt, different results across model versions. Structured output sometimes ignored my schema. Financial tables in PDFs remain a hard problem. I needed OCR.space as a backup for messy scans. The messy financial tables broke OCR repeatedly, requiring the demo-friendly PDF approach.

What I Needed

Better documentation on model capabilities. Clearer error messages when context windows overflow. Native support for financial table extraction without custom preprocessing. More predictable structured output formatting for financial data.

Who This Is For

Credexia serves Credit Risk Analysts, Loan Agency Teams, Syndicated Loan Traders, Treasury Operations, ESG Compliance Teams, and Audit & Regulatory Teams. Eventually it will serve rating agencies, regulators, and institutional investors. This is not consumer SaaS. This is institutional infrastructure.

Business Model

Monetization can happen through per-loan subscription, per-document processing fees, per-settlement fees, compliance enterprise licenses, ESG pricing modules, and audit trail services.

What's Next

Credexia is not a hackathon toy. It is institutional infrastructure. I am adding real-time ESG covenant monitoring, expanding to trade settlement workflows, and building out the audit trail for regulatory compliance.

Gemini got me from idea to working demo in 48 hours. The next 48 days are about making it production-grade. The architecture is real. The global state works. The blockchain sealing provides immutable audit trails. The payment waterfall guarantees zero variance. The AI extraction learns from every validation.

The foundation is built. Now it is time to scale.

Built with Next.js, Supabase, Polygon, and Google Gemini.

Bridgy: Helping Overwhelmed Communities Choose the Right Tool, Not Another Tool

Agastya Khati — Mon, 02 Mar 2026 04:32:18 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

A few months ago, a friend reached out to him late at night.

“Do you know any tool that can actually help with this? I’ve been searching for an hour and now I’m more overwhelmed than when I started.”

The friend was a college student. Smart, capable, constantly juggling assignments, exams, and expectations.

He also had ADHD.

The problem wasn’t a lack of tools it was the opposite.

Productivity apps. ADHD planners. Focus tools. Study systems. Recommendation threads. Endless “best apps” lists.

Each search added another decision.

Each decision increased the cognitive load.

By the time the search ended, nothing had been chosen and the overwhelm had only grown.

The person reading that message understood immediately.

He is part of the same overlapping communities:

a college student
a developer
someone living with ADHD

In these communities, the hardest part is often not execution it’s starting.

And starting means choosing. Choosing means evaluating options. And evaluating options is exhausting when your brain is already overloaded.

What actually helped wasn’t finding another tool.

What helped was when someone narrowed the field and said:

“Based on what you’re dealing with right now, start here.”

Bridgy is built for that moment.

What I Built

Bridgy is a transparent, rule based resource matching web app designed to reduce decision paralysis not add to it.

Instead of asking users to browse endlessly, Bridgy:

Accepts natural language input or a simple 3 question guided flow
Interprets context (community, problem, urgency)
Matches users to 2–3 curated resources
Explains why each resource was selected
Suggests one concrete next action

There are:

no black-box recommendations
no scraping
no tracking
no stored personal data

Every recommendation is deterministic and explainable.

AI is used only to understand language and rewrite explanations empathetically never to decide what resources are shown.

Demo

Video Demo

Code

GitHub Repository

kris70lesgo / bridgy

Bridgy

Transparent, rule-based resource matching for neurodivergent minds.

Bridgy helps people with ADHD, autism, dyslexia, anxiety, depression, and related conditions find the right tools and support — without black-box algorithms, data collection, or tracking. Every recommendation is deterministic and explainable.

Overview

Bridgy is a static-first, privacy-first web app. Users describe what they need — either by answering a short guided questionnaire or typing freely — and Bridgy matches them to a curated set of 32+ resources using a fully transparent, deterministic scoring engine.

There is no backend database, no user accounts, no analytics, and no data sent to third parties beyond an optional LLM call to parse free-text input. The entire matching logic lives in client-side code that anyone can read.

…

View on GitHub

The full codebase is open and readable.

All matching logic, scoring rules, and data models live in the repository.

How I Built It

Architecture Philosophy

Bridgy is intentionally:

Static-first
Privacy-first
Explainable by design

There is:

no backend database
no user accounts
no analytics
no stored user data

The app works fully even without an API key.

Tech Stack

Layer	Technology
Framework	Next.js 16 (App Router)
Language	TypeScript (strict)
UI	React 19
Styling	Tailwind CSS v4
Icons	Lucide React
LLM Gateway	OpenRouter (GLM-4.5 → Gemini 2.0 Flash fallback)
Deployment	Vercel

How Bridgy Works

User Input
- Guided mode (community → problem → urgency)
- OR free-text natural language
Intent Parsing
- Free text is parsed into structured intent using GLM-4.5
- Falls back to Gemini 2.0 Flash
- If no API key exists, a keyword-based local parser runs instead
Deterministic Scoring
- Community match: +3
- Problem match: +3
- Urgency match: +1
- Human support (when requested): +2

Same input always produces the same ranked output.

Transparent Results
- 2–3 matched resources
- “Why this?” explanations
- One clear next action

Why These Decisions Matter

Bridgy deliberately avoids:

web scraping
live search
user tracking
black-box AI recommendations

For people who are already overwhelmed, trust and clarity matter more than clever automation.

Every design decision was made to reduce cognitive load not increase it.

Closing

Technology has done a great job building tools for communities.

It has done a much worse job helping people navigate between them.

Bridgy is a small attempt to bridge that gap not by adding more options, but by helping someone take one clear step forward when everything feels like too much.

Sometimes, that’s enough to change the direction of a day.

Copilot Sherlock : Governed Incident Investigation CLI

Agastya Khati — Sun, 15 Feb 2026 16:14:19 +0000

This is a submission for the GitHub Copilot CLI Challenge

Copilot Sherlock — Governed Incident Investigation CLI

AI proposes. Humans decide. The system verifies.

What I Built

I built Sherlock, a CLI-based incident investigation system that demonstrates how to use GitHub Copilot CLI inside a real production-style workflow, not just as a code generator or chat assistant.

Sherlock turns raw production evidence (logs, metrics, deployments) into a governed, auditable incident decision with a strict lifecycle:

AI performs bounded reasoning
Humans explicitly decide (ACCEPT / MODIFY / REJECT)
The system enforces authority and lifecycle rules
Outcomes are recorded as append-only organizational memory
All artifacts are cryptographically verifiable

AI never decides. Humans always decide.

This is not an AI demo.
It’s an incident lifecycle system with AI inside it.

The 90-Second Pitch

Most incident tools do one of two things:

Give you AI suggestions with no governance
Give you checklists with no intelligence

Sherlock separates intelligence from authority:

AI proposes multiple competing hypotheses with evidence and confidence
Humans approve or reject the outcome
The system enforces lifecycle gates, memory isolation, and execution rules
Every decision is immutable and externally verifiable

There are no feedback loops, no auto-approval, and no adaptive behavior.

This is what production-grade AI assistance looks like.

Demo

Video Walkthrough (Full End-to-End Run)

GitHub Repository

https://github.com/kris70lesgo/sherlock-demo

One-Command Demo

./run-demo.sh

This executes the entire incident lifecycle:

Evidence normalization and trust validation
Scope reduction (thousands of log lines → a few signals)
AI hypothesis reasoning using GitHub Copilot CLI
Mandatory human governance (ACCEPT / MODIFY / REJECT)
Organizational memory write (append only, read only)
Operational integration (Slack / JIRA simulation)
Cryptographic provenance and trust report generation

Fresh Incident IDs

To avoid append-only memory conflicts, you can run:

./sherlock investigate INC-999

Copilot Auth vs Offline Mode

Sherlock uses GitHub Copilot CLI for Phase 3 reasoning when authenticated.

If Copilot is not authenticated, Sherlock falls back to an offline post-mortem generator so the demo still completes.

To authenticate Copilot:

gh auth login

My Experience with GitHub Copilot CLI

Copilot CLI was used as a reasoning engine, not as an authority.

Specifically:

Copilot generates multi-hypothesis RCAs from scoped evidence
Each hypothesis includes:
- Evidence FOR
- Evidence AGAINST
- Confidence contribution
Confidence is budgeted and uncertainty is explicit
Hypotheses can be ruled out with justification

Crucially:

Copilot cannot finalize anything
It cannot approve itself
It cannot modify governance rules
Its output is preserved even when rejected

The most valuable aspect of Copilot CLI here wasn’t speed it was structured reasoning under constraints.
Once those constraints were clear, Copilot became a reliable component in a larger system instead of a black box.

Why This Matters

Sherlock demonstrates:

How to use Copilot CLI inside a production workflow
How to prevent AI feedback loops
How to enforce human authority mechanically
How to make AI output externally verifiable
How to integrate AI without letting it run the system

Most tools ask you to trust them.

Sherlock gives you a way to verify them.

That’s the difference between a demo and a product.

Final Notes

Language: Bash + Python
Interface: CLI (interactive and non-interactive modes)
Architecture: 7 phase, strictly isolated pipeline
Status: Frozen, validated, demo ready

Thanks for checking it out.

[Boost]

Agastya Khati — Sun, 01 Feb 2026 03:49:52 +0000

3D-First Portfolio Built with Antigravity

Paimon ・ Jan 31

#devchallenge #googleaichallenge #portfolio #gemini

Building a Portfolio with Gemini - New Year, New You Portfolio Challenge

Agastya Khati — Sat, 31 Jan 2026 13:50:57 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

This project started with a simple question:

What happens when you stop treating AI as a tool that writes code, and start treating it as a creative and technical collaborator?
I wanted to explore how far modern Google AI tools specifically Gemini 3 and Antigravity could take an idea when used for thinking, designing, iterating, and refining, not just generating snippets.

This portfolio is the result of that exploration.

It’s not meant to be flashy for the sake of it. It’s meant to show how clarity, motion, and structure can emerge naturally when ideas are shaped collaboratively with AI from the very first layout decision to the final animation timing.

Portfolio

Video Walkthrough

To better showcase the motion, flow, and animation details, here’s a short walkthrough of the portfolio.

This video highlights:

The hero intro animation
Scroll-based reveals and transitions
Micro-interactions and motion pacing
Overall visual flow and structure

Note on presentation

While the portfolio is fully deployed on Google Cloud Run, embedding it directly inside a DEV post limits viewport size and affects animation timing.

To preserve the intended experience, a short video walkthrough is included below, along with a direct link to view the portfolio in a full browser window.

Live Portfolio:

https://port-709587781727.us-central1.run.app/

--labels dev-tutorial=devnewyear2026

How I Built It

This portfolio was built through an AI-assisted vibe-coding workflow powered by Gemini 3 and Google Antigravity.

Rather than starting with rigid wireframes or a fixed specification, the process focused on momentum — letting ideas evolve quickly while keeping the system coherent.

Gemini 3 as a Creative and Technical Partner

Gemini 3 was used throughout development as a reasoning and design partner.

Instead of asking it to “write code,” I used Gemini to:

Explore multiple animation approaches before choosing one
Reason about motion pacing and visual hierarchy
Design section flow and narrative structure
Stress-test interaction ideas conceptually
Refine micro-interactions and transitions

Gemini helped answer questions like:

How long should an intro animation last before it feels slow?
How do you guide attention without overwhelming the user?
Where should motion stop so content can breathe?

This kind of feedback loop made it possible to move fast without losing intention.

Hero Intro Animation

One of the clearest examples of Gemini’s impact is the hero intro animation.

Instead of dropping the user into a static page, the portfolio opens with a carefully paced sequence:

The hero content begins subtly scaled down and centered
It fades in and scales up smoothly
The layout then transitions into its natural position
Supporting elements appear in a controlled, staggered flow

This animation was iterated multiple times using Gemini to evaluate:

Timing curves
Ease functions
Entry order
Emotional impact vs. speed

The result is an intro that feels cinematic but restrained designed to set tone, not steal attention.

Antigravity as the Execution Engine

While Gemini helped shape ideas, Antigravity made execution fluid.
Antigravity allowed rapid iteration across:

Component structure
Animation tuning
Layout refinements
Refactors without breaking flow

Instead of working file by file, Antigravity made it possible to think system-wide adjusting animation logic, layout, and styling together while maintaining consistency.

This kept the creative momentum high without sacrificing technical cleanliness.

Tech Stack

Next.js (App Router)
React
TypeScript
Tailwind CSS
GSAP for complex timeline animations
Framer Motion for scroll-based reveals and micro-interactions
Radix UI / shadcn for accessible primitives
Deployed on Google Cloud Run

What I’m Most Proud Of

The Flow

Nothing in this portfolio is abrupt.
Sections don’t “appear.”

They arrive.
Animations guide the eye instead of competing for attention, creating a calm, readable experience that still feels alive.

Animation Discipline

Motion is used sparingly and purposefully:

GSAP handles moments that require precision and choreography
Framer Motion handles moments that should feel natural and responsive
CSS handles everything that doesn’t need JavaScript

This balance keeps performance high and interactions smooth.

AI as an Enabler, Not a Gimmick

There’s no visible chatbot.

No AI button.
Yet AI is present in every decision.
Gemini and Antigravity didn’t replace creativity they amplified it. They made it possible to explore more ideas, discard weaker ones faster, and refine the strongest concepts with confidence.

Closing Thought

This project isn’t about a portfolio.
It’s about possibility.
It’s about what happens when developers stop asking AI to do the work and start asking it to think with them.
Gemini 3 and Antigravity didn’t just help build this site they shaped how it came to life.
And that’s the most exciting part.

[Boost]

Agastya Khati — Fri, 30 Jan 2026 05:47:37 +0000

A macOS-Inspired Operating System Portfolio Built using Antigravity

Shobhit Kapoor ・ Jan 30

#devchallenge #googleaichallenge #portfolio #gemini

From RFQ Emails to Winning Proposals: Building Tendr

Agastya Khati — Sun, 14 Dec 2025 17:11:09 +0000

This is a submission for the Xano AI-Powered Backend Challenge: **Full-Stack, AI-First Application**

What I Built

I built Tendr, an AI-powered proposal management system for contractors designed around a clean, scalable backend architecture.

Contractors typically receive RFQs (Requests for Quote) as unstructured emails. They then manually extract requirements, estimate pricing, draft proposals, track revisions, and monitor outcomes. This process is slow, inconsistent, and extremely difficult to scale or audit.

Tendr solves this problem by combining AI-driven automation with a production-grade backend built on Xano.

Instead of treating AI as a black box, Tendr focuses on structuring the entire workflow from RFQ ingestion to proposal delivery with clear data models, secure APIs, and auditable lifecycle tracking.

The application allows users to:

Securely authenticate and manage B2B-style accounts
Parse RFQ emails using AI to extract structured project data
Track RFQs through a defined pipeline (Received → Parsed → Pricing → Drafted → Sent → Won / Lost)
Generate and manage proposals with centralized pricing rules
View timelines, analytics, and historical activity backed by a normalized database

The frontend is intentionally lightweight.

The core goal of this project is to demonstrate how Xano can be used to turn AI-generated backend logic into a scalable, maintainable system, not just a prototype.

Demo

Live Application:

https://tendr-ashen.vercel.app/

Source Code:

https://github.com/kris70lesgo/Tendr

Demo Video:

AI-Assisted Backend Generation

I started by using Xano’s AI and database assistants to generate an initial backend scaffold.

Example prompt:

“Design a scalable backend for a contractor proposal management system with authentication, RFQ ingestion, AI email parsing, proposal generation, pricing rules, timelines, and analytics. Normalize the database and expose secure APIs.”

This produced:

An initial database schema
CRUD APIs for RFQs, proposals, pricing rules, and timeline events
Basic function stacks for request handling

While this AI-generated backend was functional, it was not production-ready.

The schema needed normalization, the APIs lacked ownership enforcement, and the logic was too linear to scale.

This is where human refinement became critical.

How I Refined the AI-Generated Backend in Xano

1️⃣ Database Design & Normalization

Before (AI-generated):

Overloaded tables
Weak separation between RFQs, proposals, and historical events
Limited support for analytics and auditing

After (Human-refined):

Clear, normalized tables:
- rfq
- proposal
- pricing_rule
- timeline_event
- event_log
- account and user
Explicit relationships between users, accounts, RFQs, and proposals
Timeline and event logging to track every state transition

This design makes it easy to add analytics, reporting, and future automation without rewriting core logic.

2️⃣ API Structure & Security

Before:

Generic CRUD endpoints
Minimal authorization logic

After:

Token-based authentication using Xano’s auth system
Ownership checks on all user-scoped endpoints
Clear API group separation:
- Authentication
- Members & Accounts
- RFQs
- Proposals
- Pricing Rules
- Timeline Events
- Event Logs

Each API group has a single responsibility, making the backend easier to reason about and safer to expose to a frontend.

3️⃣ Logic Refactoring & Maintainability

Before:

Long, linear function stacks
Repeated validation and persistence logic

After:

Modular, reusable function stacks
Clear separation of concerns:
- Input validation
- Data persistence
- AI processing
- Response formatting

This refactor significantly improved readability and made future changes safer.

4️⃣ Production Signals Added

To move beyond a prototype, the backend includes:

Secure authentication and role-aware accounts
Centralized pricing rules editable without frontend changes
Timeline events for every RFQ and proposal state change
Event logs for observability and debugging
Input validation and structured error handling

These features turn AI-powered workflows into reliable backend infrastructure.

My Experience with Xano

Xano’s biggest strength is that it allows AI to accelerate backend development without removing architectural control.

What stood out most:

Database Assistant for rapid schema iteration
Visual API and function stacks for complex workflows
Built-in authentication and account management
Clean integration with a Next.js frontend

Instead of fighting generated code, I could refine and harden it into a maintainable backend exactly what this challenge is about.

Final Thoughts

Tendr demonstrates how:

AI jumpstarts backend development
Human judgment makes it production-ready
Xano provides the tooling to bridge that gap cleanly

The focus of this project is not just AI output, but structure, scalability, and long-term maintainability and Xano excels at enabling that.