DEV Community: Ella

Why PostgreSQL Ignores Your Index (Sometimes), Entry #2

Ella — Sat, 11 Apr 2026 11:30:26 +0000

I Thought My Index Would Fix Everything

I added the index.

Ran the query.

And… nothing changed.

Same slow response. Same frustration.

That was the moment I realized something uncomfortable:

PostgreSQL doesn’t care about your index.

It cares about something else entirely.

The Question PostgreSQL Is Actually Answering

When you run a query, PostgreSQL is not asking:

“Do I have an index?”

It’s asking:

“What is the cheapest way to get this data?”

That’s it.

Meet `EXPLAIN ANALYZE`

If you’ve ever run:

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;

You’ve seen something like:

Index Scan using idx_orders_user_id on orders
Index Cond: (user_id = 42)
Actual Time: 0.03 ms

Here’s how to read it:

Index Scan using idx_orders_user_id
→ PostgreSQL used your index
Index Cond: (user_id = 42)
→ Condition applied inside the index
Actual Time
→ What really happened (not theory)

But here’s where things get interesting…

The Counter-Intuitive Truth

Indexes are not always faster.

Let that sink in.

Indexes are only faster when they reduce total work.

And sometimes… they don’t.

How PostgreSQL Really Decides

It follows a simple (but powerful) mental model:

Step 1: How many rows do I need?

Few rows → Index Scan
Most rows → Sequential Scan

Step 2: What does it cost to get them?

Index scan means:

Jump to index
Jump to table
Repeat (random access)

That “jumping” is expensive.

Using a Warehouse Analogy

Imagine a warehouse.

Two ways to find items:

Option A: Sequential Scan

Walk every aisle. Check every box.

Option B: Index Scan

Use a system to jump directly to shelves.

Now here’s the twist:

If you need 5 items → jumping is faster
If you need 80% of the warehouse → just walk

Jumping becomes slower than walking

That’s exactly how PostgreSQL thinks.

When PostgreSQL Ignores Your Index

Even if your index exists, PostgreSQL may skip it when:

1. The Table Is Small

Scanning everything is cheaper than using the index.

2. Your Filter Isn’t Selective

WHERE status = 'active'

If 80% of rows are “active”:

The index is of no use...

3. Index Access Is More Expensive

Indexes require:

Reading index pages
Jumping to table pages (random I/O)

PostgreSQL asks:

“Is all this jumping worth it?”

If not → Seq Scan wins

The Cost Model

PostgreSQL calculates cost based on:

Number of rows expected
Filter selectivity
Random vs sequential I/O

It does NOT follow rules like:

“Index exists → use it”

Instead:

“Which plan does the least total work?”

The Insight Most Developers Miss

Here’s the shift that changed everything for me:

Stop thinking in terms of speed. Start thinking in terms of work.

PostgreSQL is not optimizing for:

elegance
structure
your expectations

It’s optimizing for:

minimum effort to get the result

Why This Matters (Especially If You're Scaling)

At small scale:

Everything works
Mistakes are hidden

At large scale:

Wrong assumptions = slow queries
Slow queries = real problems

Understanding this early gives you an edge most devs don’t have.

Part of a Bigger Series

This is part of my Advanced Backend Learning Series where I break down concepts I’m actively learning—without the usual fluff.

Ella

Mar 27

Entry #01: My perfect API was actually drowning

#discuss #javascript #productivity #postgres

Comments

3 min read

If this clicked for you, the next posts will go deeper into Query optimization

You didn’t do anything wrong.

Your index didn’t “fail.”

You just learned the real rule:

Indexes are not faster. They are sometimes cheaper.

And PostgreSQL will always choose cheap over clever.

If this post, taught you something:

Drop a comment with something that confused you about databases
Or follow the series—next post gets even more practical

Because the goal isn’t to memorize PostgreSQL.

It’s to think like it.

I Almost Quit Tech Not Because of Code, But Because of People

Ella — Wed, 01 Apr 2026 12:55:42 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

When I first found out my passion for building things in tech, I was over the moon. I signed up for a training program, ready to learn, ready to build, ready to network. I had no idea I was about to face one of the toughest pits in my life, and it was not going to be my programming skills that would cause me problems. It was the people surrounding me.

Feeling Isolated in a World of Passion

Early on, I noticed my passion did not align with the passion levels of my peers. Their interests were different, their priorities were different. While I wanted to talk about things like coding, projects, and ideas, they wanted to talk about things like social trends, entertainment, or personal life.

At first, I tried to "fit in". I changed my habits, asked no questions in class, showed no curiosity, doing things everyone was doing and even adopted new hobbies to join their conversations. But still, I felt invisible.

Each day was a quiet struggle to be seen, to belong, and to wonder if my curiosity, my gender, or my age was the reason why I didn’t “fit” into this new environment.

The Low Point

I sank into deep depression. I was no longer confident, no longer enjoyed coding, and no longer wanted to be around anyone, even myself. Even simple interactions with others became challenges that I was failing at. I was exhausted, stressed, and overwhelmed.

There was a point where, while alone on the bus, I wondered if I was even cut out for this whole tech thing. It was like no one was going to be able to relate to me or help me through this. But even in this dark time, there was a small spark within me. That spark was my curiosity.

Rediscovering My Passion

The turning point was a slow one, and months later, I found my passion again and decided to get back to something that originally made me happy: building. I built a simple mobile application, a barter application, using React Native and Supabase.

Here is a glimpse of the application that I built:

But rebuilding that relationship with tech wasn’t just about the code. It was about my own confidence, my own voice, and my own love for what I do. It was about realizing that the people who don’t understand or appreciate my passion are not reflections of my own value.

Lessons Learned

Your curiosity is valid. Do not silence it to please others.
You don’t have to carry others’ expectations. Take care of your energy and your joy.
Connect with what you love. Even small projects or hobbies can reignite your confidence.
Share your journey. Vulnerability is a bridge to connection, for yourself and others.

Despite everything, I appreciate the experience. It was a painful one, yes, but also a lesson that there is power in sticking to who I am. Today, I feel hopeful, curious, and creative again, for myself and no one else.

If you’ve ever felt invisible in your tech journey, know that you’re not alone. What have been some of your coping mechanisms when faced with these feelings? I’d love to hear about them in the comments. Let’s lift each other up to stay curious, stay confident, and stay human.

New Post

Ella — Mon, 30 Mar 2026 07:53:53 +0000

Ella

Mar 27

Entry #01: My perfect API was actually drowning

#discuss #javascript #productivity #postgres

Comments

3 min read

Entry #01: My perfect API was actually drowning

Ella — Fri, 27 Mar 2026 16:01:21 +0000

For a long time, I believed that if my API sent back a 200 OK status code, my work as a backend developer was over. But I've come to realize that I should not only be using tools and libraries but also understand how they work. I've been using Postgres because I've heard it's the best. But I never really knew why—until now.

Welcome to Entry #01 of my journey into advanced backend architectures.

The Life of a Query

I used to think that a query goes in and comes out with the data. But the life of a query is actually very disciplined. It's like a relay race.

When I send a query to my Node.js application, a connection is made (now I’m using a connection pool to keep things stable). When this connection is made, a backend process is created. Then, Postgres determines how to retrieve this information. It could do an index scan if it can find it quickly, or it could do a sequential scan if it has to look at everything. It all depends on the query

One of the biggest mind blowers for me is that Postgres does not access the disk every time. It has something called a Shared Buffer. This is essentially a memory. If it is in that memory, it is quick. If it is not in that memory, it goes to the disk and puts it in that memory.

What happens when things go wrong?

I wanted to examine a few scenarios that would normally keep developers up at night.

Scenario 1: The Morning Spike
The Problem: At PayWave, our /wallet/balance endpoint suddenly jumped from 50ms to 500ms during the morning rush.

My Coworker Alex: "Hey, the balance check is dragging. Is the server overloaded?"

The Solution: If I'm working at a fintech firm like PayWave, and a balance check takes 500ms, it's a disaster. Instead of thinking of restarting the server, I would think about the dead tuples. If the database has a lot of old tuples that have not been vacuumed in a while, it could slow down the server significantly. I would also consider if the query actually using the index I created?

Scenario 2: The Growing Table
The Problem: At ShopSphere, our orders table grew from 2GB to 6GB in one week, but our sales didn't triple.

My Coworker Priya: "Why is the disk filling up so fast? The autovacuum is on, so it shouldn't be a bloat, right?"

The Solution: If a table has tripled in size in a week at ShopSphere, it could be a sign of that it's a bloat. Even if autovacuum is enabled, it may not be fast enough to keep up with the volume of changes to the table. I would examine the value of autovacuum_vacuum_cost_limit to determine if we are slowing down the autovacuum process too much.

Scenario 3: The Mid-Transaction Crash
The Problem: During a quarterly DR test at CryptoBank, we simulate a primary node crash mid-transaction.

My Coworker Sam: "We killed the primary node. Can we actually restore this without losing the last 30 seconds of transactions?"

The Solution: This used to worry me. But after learning about Write Ahead Logging (WAL), I don’t worry about this anymore. Even in the case of a primary node crash, I know that I the data can be recovered. I can simply replay all the logs and bring my system to a consistent state.

My Key Takeaways

Indexing is your friend when it comes to speed.
Bloating is a silent killer; do monitor dead tuples.
Using connection pools avoids the "Too Many Connections" crash because it manages backend processes.

I'm shifting my focus from merely coding to learning about the environment that runs my code. If you have any questions/scenarios related to Postgres performance tuning, do share in the comments below.

Catch you in Entry #02.

Connect with me

EllaFollow

Building little things & documenting my coding journey

Check out my previous post:

Ella

Mar 12

Fintech Companies Lose Millions From Missed Filings — So I Built This API

#node #api #backend #javascript

Comments

3 min read

new post

Ella — Sat, 21 Mar 2026 13:55:49 +0000

Ella

Mar 20

I built a payment proof tracker for agencies fed up of “I’ve paid” messages

#webdev #backend #javascript

Comments 10

2 min read

I built a payment proof tracker for agencies fed up of “I’ve paid” messages

Ella — Fri, 20 Mar 2026 11:34:26 +0000

The Problem:

Every freelancer or agency has encountered the following scenario at some point:

Client says: "I've paid"
You ask for proof of payment
Client sends a random screenshot
You scroll through your chat logs trying to find a match for a project
Your spreadsheet is outdated and useless
Your team has no idea what's been paid and what has not been paid

It gets messy real quick.

And it's not just about money... it's about trust, verification, and visibility among your team members.

What I Built

I built ProofPay API. It is a lightweight backend for payment tracking and proof verification.

It allows you to:

Track payments from your clients
Upload and verify payment proofs
Manage projects and track the status of payments
Provide teams with a unified overview of what is paid and what is pending

Instead of using chats and spreadsheets to keep track of everything, everything is now in one system.

What It Does

Authentication: User Registration & Login, JWT-based authentication
Projects: Create client projects, Add payments to projects & Project status tracking
Payments: Record payments per project, Add proof to payments (image, file, reference), Mark payments as (pending, verified, rejected)
Team / Agencies: Multiple users under a single workspace, Visibility to all team members
Dashboard: Overview of (total payments, pending proofs, verified transactions)

Example Flow:

So, here is an example of how it would work:

Create a project
Add a payment
Client uploads proof
You verify or reject it
Dashboard updates automatically

No more guessing. No more “check WhatsApp”.

API Example

Here’s what a typical request looks like:

Create Payment:

POST /payments

Headers:
Authorization: Bearer <token>

Body:
{
  "projectId": "123",
  "amount": 50000,
  "method": "bank_transfer",
  "proofUrl": "https://..."
}

Tech Stack

Backend: Node.js (Express / TypeScript)
Database: Postgresql
Auth: JWT
Docs: Postman (auto-generated)

Docs

You can explore the full API here:
https://documenter.getpostman.com/view/43051527/2sBXijHWgD

Why I Built It This Way

I didn’t want to overcomplicate things.

No heavy “fintech” system
No unnecessary abstractions

Just:

clear endpoints
simple flows
real-world usefulness

What This Doesn’t Do

It’s not a payment processor (like Stripe)
It doesn’t move money
It focuses purely on tracking + verification

Is This Actually Useful?

Honestly:

For solo freelancers: helps you stay organized
For agencies: offers team-wide visibility
For clients: adds accountability

It’s not trying to replace payment processors.

It does just one thing exceptionally well:

“Has this client actually paid?”

What Next

Notifications for payment verification
Improvements for reporting and exports
Frontend dashboard (maybe 👀)

Feedback I Want

Would you actually use this in your workflow?
What’s missing for real-world usage?
Does the API structure make sense?

Fintech Companies Lose Millions From Missed Filings — So I Built This API

Ella — Thu, 12 Mar 2026 10:57:49 +0000

Industries like fintech, healthcare, and insurance operate in heavily regulated environments. Every quarter, month, or year they must submit filings, complete audits, renew licenses, and comply with regulatory requirements.

Missing a deadline can be extremely expensive.

A delayed filing might cost thousands per day in penalties, not to mention reputational damage and the legal consequences a company may face.

Despite this, many compliance teams still track obligations using:

spreadsheets
emails
calendar reminders

That got me thinking:

What if compliance deadlines could be analyzed automatically through an API?

So I built a Regulatory Compliance Deadline Tracker API using Node.js and Express.

This API accepts compliance obligations, calculates the remaining time before deadlines, categorizes risk levels, and flags urgent items — all in a single request.

The Problem

Industries like finance, fintech, healthcare, and insurance deal with dozens (sometimes hundreds) of regulatory obligations.

Examples include:

Quarterly financial filings
Data protection audits
Regulatory reports
License renewals
Compliance certifications

Tracking these manually can lead to problems such as:

missed regulatory filings
late compliance submissions
expired licenses
unexpected financial penalties

A small automation layer could dramatically reduce these risks.

The Idea

The goal of the API is simple:

Accept a list of compliance obligations
Calculate how many days remain until each deadline
Categorize the risk level
Identify urgent items
Estimate penalty exposure if deadlines are missed

Instead of storing data in a database, the API works entirely from the request payload.

This keeps the API lightweight and makes it easy to integrate into:

dashboards
internal tools
automation systems

API Endpoint Design

The API exposes a single endpoint:

POST /analyze-deadlines

It accepts:

a company name
the current date
a list of regulatory obligations

These fields are required. If they are missing, the API returns a 400 Bad Request response.

Example Request

{
  "company": "ABC Corp",
  "today": "2026-03-01",
  "obligations": [
    {
      "name": "Quarterly Financial Filing",
      "dueDate": "2026-03-15",
      "penaltyPerDay": 5000
    },
    {
      "name": "Data Protection Audit",
      "dueDate": "2026-03-05",
      "penaltyPerDay": 20000
    }
  ]
}

Example Response (As of 12/03/2026)

{
    "company": "ABC Corp",
    "analysis": [
        {
            "name": "Quarterly Financial Filing",
            "daysRemaining": 3,
            "riskLevel": "HIGH"
        },
        {
            "name": "Data Protection Audit",
            "daysRemaining": -7,
            "riskLevel": "CRITICAL",
            "penaltyExposure": 140000
        }
    ],
    "totalPenaltyExposureIfLateToday": 140000
}

The response returns a structured analysis showing:

the number of days remaining
the risk level of each obligation
the overall penalty exposure

Example API Call in Postman

Below is the API running in Postman.

How the Risk Calculation Works

The API evaluates each compliance obligation and calculates how many days remain before the deadline.

The risk level is determined using a simple classification system.

Days Remaining	Risk Level
< 0 days	CRITICAL
1 – 9 days	HIGH
10 – 30 days	MEDIUM
> 30 days	LOW

This allows compliance teams to quickly identify urgent filings.

Implementation with Node.js and Express

The API was built using a simple Node.js + Express backend.

Key concepts implemented in this project include:

date parsing
mathematical calculations
conditional logic
data transformation
structured JSON responses
API error handling

Potential Real-World Use Cases

This type of API could power several real systems.

Compliance Dashboards

Internal tools that monitor regulatory deadlines.
Fintech Risk Monitoring

Automatically identify high-risk regulatory obligations.
Compliance Automation Platforms

Trigger alerts or workflows when deadlines approach.
Regulatory Alert Systems

Send notifications when filings become urgent.

Why I Built This

Many developer tutorials focus on simple projects like todo list APIs.

While those are useful for learning, I wanted to build something closer to real enterprise software problems.

Compliance automation is an area where small tools can have massive financial impact.

Even a simple API like this could help teams identify risk before penalties occur.

Future Improvements

Some potential improvements include:

automatic penalty calculations for overdue filings
email or Slack alerts for urgent deadlines
recurring regulatory obligations
integration with compliance management platforms
persistent storage using a database

GitHub Repository

If you'd like to explore the code or test the API yourself, the full project is available on GitHub.

You can find it here: GitHub Repository Link

Feel free to clone the project, experiment with the API, or suggest improvements.

Final Thoughts

Regulatory compliance might not sound glamorous, but it is a huge operational challenge for regulated industries.

Even small tools that improve visibility around deadlines can help companies avoid costly penalties and reduce compliance risk.

If you found this interesting, feel free to check out my previous posts and consider following me for more backend and API development content:

I Built a Procurement Quotation Comparator API (Node.js + TypeScript)

Ella — Fri, 06 Mar 2026 12:18:53 +0000

Liquid syntax error: 'card' tag was never closed

Why I’m building a 3-Tier Architecture (and why 2-tier aren't enough)

Ella — Tue, 17 Feb 2026 10:46:06 +0000

I’ve lately been trying to drive deeper into my skills and realized something: it’s very easy to build a 2-tier application "Todo List," but if you want to build something that actually survives the real world, you have to understand the "why" behind the layers.

This is me learning in public, and here is what I’m mastering this week:

I’ve started practicing this more because it’s more professional. It stops me from letting my Frontend talk directly to my Database, which is basically a security nightmare! Using a Backend middleman (Node.js/Express) to handle the logic keeps the data safe and the architecture clean.

Second, I used to think a domain name was just a label. Now I see it as a complex routing system using A Records to point to global servers. Understanding how it asks your computer, goes to the Top Level Domain, and finally finds your IP has been eye-opening. It definitely explains why some sites take a bit to load

Third, there’s something wild about knowing that anytime I send a message, it is broken into tiny chunks and reassembled perfectly using TCP when it reaches the receiver's IP address.

Honestly, recalling the DNS process was not easy. It’s a lot of steps! I’ve been using AI to breakdown the parts that didn't click, and it has been a total game-changer for my learning speed.

My Goal: I don't just want to "code," I want to understand the systems that make the code run.

To the seniors in the industry:
What is the one networking concept you wish you had learned sooner in your career, that you still use in your day-to-day runs?

Let’s chat in the comments ↆↆↆ

I Built a "Command Center" for My Job Hunt Because Spreadsheets Are Where Dreams Go to Die

Ella — Wed, 11 Feb 2026 11:55:01 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built Jhella, a terminal-based "Command Center" for developers who are officially done with messy job-hunt spreadsheets.

We’ve all been there: 47 LinkedIn tabs open, a flooded inbox, and a spreadsheet named Job_Hunt_Final_v3_REAL_THIS_TIME.xlsx that is a total disaster by week two. I got tired of tracking my high-tech career in a low-tech table, so I built a tool that lives where I do: the terminal. Jhella lets me log applications, auto-convert salary shorthand (like typing $120k and having it actually save as $120,000), and get visual ⚠️ alerts if I haven't followed up on an application in 7 days.

Demo

You can try Jhella right now without even installing it:
npx jobhunt-ella-cli

NPM Package: jobhunt-ella-cli
GitHub Repository: Jhella Source Code

📸 Screenshots

The view I check every morning to make sure I'm not getting ghosted.	The step-by-step way I add new job leads.
I type $150k and Jhella actually knows what I mean.	A little motivation, seeing the 'Potential Max' salary helps on the tough days.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI was basically my pair programmer for this whole build. Here’s how it actually helped:

No more Tab-Switching: I used gh copilot explain whenever I got confused by commander.js or inquirer. It saved me from constant context-switching between my code and documentation.
Regex without the Headache: Honestly, I probably would have spent hours fighting with Regex patterns for the salary parser if I hadn't just asked Copilot CLI to help me generate the logic for currency shorthand.
Fixing my NPM drama: When I hit a 403 Forbidden error trying to publish my first package, I used the CLI to troubleshoot my 2FA and auth settings without ever leaving the terminal.

Instead of getting stuck on CLI boilerplate, Copilot CLI let me focus on making Jhella actually useful for my job hunt.

✨ Support & Connect

If Jhella helps you stay organized (or you just want to support a fellow dev on the hunt), I’d love your support:

Star the Repo: Jhella on GitHub ⭐
Follow me on DEV: @git-ellea
Try the Tool: npx jobhunt-ella-cli

Good luck to everyone else in the challenge!

githubcopilotclichallenge #productivity #typescript #career

Scaling Intelligence: How I Built a 1,500-Item AI Shopping Assistant with Next.js & Algolia

Ella — Sun, 08 Feb 2026 07:37:09 +0000

This is a submission for the Algolia Agent Studio Challenge: Consumer-Facing Conversational Experiences

What I Built

We've all been there: scrolling through 50 pages of products, filtering, unfiltering, and still not finding that one thing that fits our budget. It’s exhausting.

I built Inventory Pro to kill "search fatigue" once and for all. It’s an AI-driven shopping assistant designed to turn a massive 1,500-item catalog into a simple, human conversation. Instead of clicking endless buttons, users just ask: "I have ₦20,000, what accessories can I afford in the Lekki warehouse?" The result? A grounded, dialogue-based experience where the AI doesn't just "guess", it retrieves real-time data to give accurate, reliable shopping advice.

Demo

Live App: Inventory Pro

Key Highlights


The clean, intuitive interface designed for fast communication.	Context-aware responses that understand price, location, and availability.

Intelligent Comparison: No more switching tabs. The agent generates Markdown tables on the fly so you can compare prices and specs side-by-side.

Out-of-Stock Alerts: Using custom Orange Highlights, the agent warns you immediately if an item is unavailable, even providing the exact date it will be back.
Enterprise Scale: I scaled the backend to 1,500 diverse products to ensure the AI could handle real-world inventory pressure without breaking a sweat.

How I Used Algolia Agent Studio

I treated Algolia Agent Studio as the "Truth Engine" for my Google Gemini model.

The Index: I indexed 1,500 records including price, stock_level, warehouse_location, category, and restock_date.
Retrieval-Augmented Dialogue: By using Algolia’s retrieval, I eliminated AI "hallucinations." The assistant only talks about what is actually in the database.
Prompt Engineering: I engineered the system prompts to act as a "Pro-Active Shop Manager." I specifically instructed the agent to monitor stock levels and proactively warn users if an item is low (under 5 units) using custom formatting.

Why Fast Retrieval Matters

When you're dealing with 1,500 products, a standard LLM is like a librarian trying to memorize the entire building, it’s slow and prone to mistakes.

Algolia is the digital catalog. It filters thousands of items in milliseconds. Even on a Free Tier plan, where I encountered some rate-limit latency, Algolia ensured that once the "thinking" was done, the data returned was 100% accurate. This speed transforms the experience from a "clunky chatbot" into a reliable, high-performance shopping tool.

🙌 Let's Connect!

Building this was a journey of debugging and discovery (especially getting those 1,500 items to play nice!). If you’ve ever struggled with AI rate limits or scaling data, I’d love to hear your story in the comments!

If you found this cool, drop a ❤️ and follow for more!

DEV Community: Ella

Why PostgreSQL Ignores Your Index (Sometimes), Entry #2

I Thought My Index Would Fix Everything

The Question PostgreSQL Is Actually Answering

Meet EXPLAIN ANALYZE

The Counter-Intuitive Truth

How PostgreSQL Really Decides

Step 1: How many rows do I need?

Step 2: What does it cost to get them?

Using a Warehouse Analogy

Option A: Sequential Scan

Option B: Index Scan

When PostgreSQL Ignores Your Index

1. The Table Is Small

2. Your Filter Isn’t Selective

3. Index Access Is More Expensive

The Cost Model

The Insight Most Developers Miss

Why This Matters (Especially If You're Scaling)

Part of a Bigger Series

Entry #01: My perfect API was actually drowning

I Almost Quit Tech Not Because of Code, But Because of People

Feeling Isolated in a World of Passion

The Low Point

Rediscovering My Passion

Lessons Learned

New Post

Entry #01: My perfect API was actually drowning

Entry #01: My perfect API was actually drowning

The Life of a Query

What happens when things go wrong?

My Key Takeaways

Connect with me

EllaFollow

Fintech Companies Lose Millions From Missed Filings — So I Built This API

new post

I built a payment proof tracker for agencies fed up of “I’ve paid” messages

I built a payment proof tracker for agencies fed up of “I’ve paid” messages

What I Built

What It Does

Example Flow:

API Example

Tech Stack

Docs

Why I Built It This Way

What This Doesn’t Do

Is This Actually Useful?

What Next

Feedback I Want

Fintech Companies Lose Millions From Missed Filings — So I Built This API

The Problem

The Idea

API Endpoint Design

Example Request

Example Response (As of 12/03/2026)

Example API Call in Postman

How the Risk Calculation Works

Implementation with Node.js and Express

Potential Real-World Use Cases

Compliance Dashboards

Fintech Risk Monitoring

Compliance Automation Platforms

Regulatory Alert Systems

Why I Built This

Future Improvements

GitHub Repository

Final Thoughts

I Built a Procurement Quotation Comparator API (Node.js + TypeScript)

Why I’m building a 3-Tier Architecture (and why 2-tier aren't enough)

I Built a "Command Center" for My Job Hunt Because Spreadsheets Are Where Dreams Go to Die

What I Built

Demo

📸 Screenshots

My Experience with GitHub Copilot CLI

✨ Support & Connect

githubcopilotclichallenge #productivity #typescript #career

Scaling Intelligence: How I Built a 1,500-Item AI Shopping Assistant with Next.js & Algolia

What I Built

Demo

Key Highlights

Meet `EXPLAIN ANALYZE`