Intro
FreightRate AI is an in-progress backend project focused on logistics rate calculation. I wanted to build something stronger than a generic CRUD app, and freight pricing gives me that opportunity because the rules are real.
The project connects my logistics exposure with modern backend engineering. It lets me practice .NET 8 Web API, PostgreSQL, Docker, Redis caching plans, Google Cloud Run deployment planning, and AI-assisted explanations.
Why I worked on this
I worked on this because freight pricing is a business problem with enough complexity to make the backend meaningful. It is not only about saving and fetching records. The system has to calculate, compare, and explain.
I also wanted a project that reflects the kind of systems I care about: backend-heavy applications where rules, data modeling, correctness, and clear service boundaries matter.
What problem I was trying to solve
Freight pricing is not a simple fixed-rate calculation. A quote can depend on origin, destination, pincode or zone, actual weight, volumetric weight, chargeable weight, carrier, service type, surcharge, GST, and business-specific rules.
A useful quote system should compare carrier-wise rates and help the user understand the recommendation. The recommendation could be cheapest, fastest, or balanced depending on the business goal.
The challenge is making the calculation deterministic while still making the output understandable.
How I approached it
I am designing the quote flow around clear backend steps. A request comes in with shipment details. The API validates the input, resolves zones, calculates chargeable weight, selects carrier pricing rules, applies surcharges and taxes, and returns a structured quote breakdown.
The quote service is responsible for deterministic calculation. AI should not invent pricing. Instead, the AI explanation layer should explain why a carrier was selected or why one option is cheaper than another.
Redis is planned for caching data that is read often, such as zone mappings, carrier data, and frequently used rate configurations. Docker helps keep local development consistent. Google Cloud Run is planned as the deployment target once the core flow is stable.
I am also thinking about quote comparison as a separate concern from quote calculation. The calculation should produce reliable carrier-wise results. The comparison layer can then decide whether to recommend the cheapest, fastest, or balanced option. Keeping those responsibilities separate should make the system easier to test and change later.
What I learned technically
I am learning that pricing systems need careful boundaries. Zone resolution, chargeable weight calculation, carrier rule selection, surcharge calculation, and recommendation logic should not be mixed into one large method.
I am also learning to think about caching more practically. Redis is useful, but only if I understand what data is repeated and how often it changes.
The AI part is also teaching me an important boundary: AI can explain a result, but the business calculation should remain testable and deterministic.
Another technical lesson is that every calculated value should be traceable. If the final quote includes chargeable weight, surcharge, GST, and a minimum charge adjustment, the response should expose enough of that breakdown to debug and explain the result. That is useful for developers and for users.
This also affects database design. Carrier rules, zones, and charges need to be stored in a way that supports change. If the tables are too close to one hard-coded scenario, every new rule becomes painful. If they are too generic, the system becomes hard to reason about. I am trying to stay in the middle.
Mistakes or confusing parts
One confusing part is deciding how flexible the rate model should be. If it is too rigid, future carrier rules become hard to add. If it is too abstract, the system becomes difficult to understand.
Another risk is adding AI too early. The pricing engine must work first. The explanation layer should come after the quote breakdown is reliable.
What I would improve next
Next improvements include authentication, admin rate upload, Excel import for rate sheets, more test cases, better quote comparison, and a clearer recommendation model.
I also want to add sample data and diagrams so the case study becomes easier to understand for recruiters and other developers.
Final takeaway
FreightRate AI is valuable because it practices real backend design. It combines business rules, data modeling, caching, deployment planning, and explainability without pretending AI should replace deterministic logic.