I posted a bit about this job already. The MacBook. The XGBoost rabbit hole. The general chaos of doing too many things at once.
But I want to write the longer version here. The honest one. Because what has been happening at this job over the last few weeks deserves more than a surface level update.
What This Job Actually Is
I am a Pricing and Tech Associate at an international freight forwarding company. Part time. Which sounds like a mouthful but in practice means I am the person responsible for the entire tech overhaul of the business.
Not advising on it. Not presenting a roadmap in a slide deck and handing it off. Actually doing it.
That distinction matters. And it is the reason I chose this over a regular internship.
The Things I Have Already Shipped
Before I get into the big stuff, let me just quickly cover what has been done so far.
I built the founder's personal portfolio website. Full blog system backed by Sanity CMS so he can add posts and categories without touching code. It is live. It works. Someone is using it every week to publish content.
I have made multiple presentation decks. Company profile, pitch materials, internal documents. This sounds simple but sitting down to communicate what a business does, cleanly and clearly, teaches you a lot about the business itself.
And then there is the XGBoost price predictor I wrote about before. The idea being that freight quotes right now take too long because a person has to manually work through variables across carriers, trade lanes, and conditions. The goal is to build something that can give a fast, reasonably accurate prediction. I had never touched ML before this. Now I have.
These are all real things. Shipped or in progress. Not tutorial projects.
The Thing I Am Most Focused On Right Now
There is a much larger project that I have been thinking through for weeks and have only recently started architecting properly.
A customer facing platform. A full dashboard where clients can log in, add a booking, compare rates across multiple vendors, track their shipments, and manage a wallet for payments.
When I first heard the scope I remember thinking this is a lot. And it is. But the more I have sat with it the more I have realised what makes it genuinely hard is not the CRUD layer. It is not auth or the UI or even the wallet system. Those are all solvable problems with clear paths.
What makes this hard is the vendor integration problem.
Multiple Vendors, Multiple APIs, One Platform
Here is the actual complexity.
We work with multiple vendors. Some specialise in specific trade lanes. Some are channel partners of companies like UPS or FedEx, which means they can offer better rates on certain routes than going directly.
Each vendor has their own API. Their own structure for requesting rates. Their own response shape for booking confirmations. Their own webhook format for tracking events. Their own error codes. Their own quirks.
And I need to build one unified platform on top of all of it.
The customer hits one interface. They enter shipment details. They see a clean comparison of rates. They book. They track. They have no idea that behind the scenes five different APIs with five completely different structures are being called, normalised, and stitched together into one coherent view.
This is not a toy CRUD app. Real bookings would be made through this. Real money would move. Real shipments. The stakes are not academic.
Why the Adapter Pattern Is Probably the Only Viable Approach
I have been thinking through the architecture for a while now and I keep landing in the same place.
The adapter pattern. Or more specifically, a typed master interface in TypeScript that defines the canonical shape for everything. Rate requests, rate responses, booking inputs, booking confirmations, tracking events. One shape to rule them all.
Each vendor gets its own adapter that does two things. Takes the canonical input and translates it into whatever that vendor's API actually expects. Then takes whatever that vendor's API returns and translates it back into the canonical shape.
So from the platform's perspective, every vendor behaves identically. You call getRate(canonicalInput) and you get back CanonicalRateResponse. What happens inside the adapter is the vendor's problem, not the platform's.
The TypeScript interfaces here are not optional decoration. They are the contract that holds the whole thing together. If an adapter does not satisfy the interface, it does not compile. That is the safety net.
If I pull this off cleanly it would be one of the better engineering decisions I have made. Not because it is clever. Because it is the only approach that makes the system actually maintainable as we add more vendors over time.
How I Am Thinking About the Rollout
I am not trying to build everything at once. That is a good way to build nothing.
The first thing I want to ship is tracking. Just tracking.
Here is the reasoning. Right now bookings are made manually on vendor platforms. Clients have no visibility. They call or email to ask where their shipment is and someone has to go check. That is slow and it is not a good client experience.
If I can surface tracking through our interface, even while booking is still manual, clients start seeing our company logo and our UI every time they check their shipment status. That builds trust. That makes the platform feel real before it is fully real.
Tracking is also the most self contained piece. I can build the adapter interface, implement it for one or two vendors, and have something useful without needing the full booking or rate comparison system to be done.
After that, rate comparison. But initially only for internal use. The team can use it to get faster quotes. Once we have confidence in the accuracy and reliability we open it to clients. You do not show clients something you have not tested thoroughly yourself first.
Booking and the wallet come later. Phase by phase.
The Things Nobody Warned Me I Would Learn
I have been doing data analytics in Excel.
I say this with some amusement because I have actively avoided Excel my entire student life. I always thought it was a tool for people who did not know how to code. Which is a silly and wrong thing to believe.
The actual task: we exported the founder's LinkedIn connection data. Thousands of connections. The goal is to segregate these into relevant categories for a targeted email campaign. Different message for a logistics professional than for a startup founder than for a corporate procurement manager.
I learned VLOOKUP on the spot. Learned how to use filters to build clean segmentation. Learned that data, even messy human generated data from a social network, has structure you can find if you look carefully enough.
And now I am looking into data enrichment tools. The connection data we have is shallow. Name, company, job title. But for an email campaign to actually land, you want to know more. Industry, company size, recent activity. There are tools that can fill those gaps. I am learning which ones are worth using and what the cost benefit looks like.
This is not what I expected to be doing. But it is genuinely useful and it is making me a more complete person to have in a business context.
LinkedIn Content Strategy
I have been running the LinkedIn content strategy for the founder's personal account.
Three posts published so far. Each one trying to do a specific thing: build his authority in the freight and logistics space, make his name feel trustworthy and knowledgeable to the kind of people who might eventually send business his way.
LinkedIn content is its own craft. It is not blog writing. It is not technical writing. The feed is brutal. Most content gets ignored within seconds. If the first line does not stop the scroll nothing else matters.
I have been thinking a lot about the difference between content that performs and content that actually builds authority over time. They are not always the same thing. Viral posts and credibility building posts often look very different.
I am learning this by doing it. Which is the only real way to learn it.
Being in the Room
I have been going to meetings with the founder. Visiting shipment hubs. I have been to the Aramex hub. FedEx is coming.
This sounds like a minor detail but it is actually the part I think about most.
When you are inside an industry, you stop theorising about what the problems might be and you just see them. Running on a spreadsheet they should not be running on. A process that takes four people to do what one good tool could handle in seconds. A client experience that makes people anxious because there is no visibility.
You see these things and you immediately start thinking about solutions. Not because you are trying to. Just because that is how a developer's brain works when it is properly calibrated to a real context.
My boss has decades of experience. Aramex, UPS, FedEx, Jeena, DG Group. He is not teaching me by handing me documents. He teaches by taking me places and explaining what I am looking at. That is a very different kind of education and it is sticking in a way that documentation never quite does.
The Philosophy of It All
Something I have been sitting with lately.
In most internships you go in, you do what you are told, you learn the tools, and you leave. The company does not really get better because you were there. You get better. But the company was going to be fine either way.
This is different. The decisions I am making here have real consequences for a real business. If I build the platform well and it works, clients will use it. The company will grow. If I build it poorly or slowly, that is a real cost.
I have been thinking about this a lot: what does it actually mean to care about something as if it is your own? Not in the abstract, but in practice. It means you think about it when you are not working. You question your own decisions. You are honest about what you do not know. You do not let things sit when they could be moving.
I think if I ever start something of my own, the mindset I am building right now is going to matter more than any specific technical skill.
Where Things Actually Are
My end semester exams start on the 26th of May. They run until mid June. So there is a pause coming, which is a bit frustrating because the momentum has been good.
But we have used the time before exams well. The foundation is solid. The thinking is done. The architecture is clear. By the end of June, when I am fully back in, I think we will be at a genuinely better position than when I started.
The tracking feature is the first milestone. Then rate comparison internally. Then outward.
I will keep writing about this. Not just the code but the whole thing. What it is like to be inside a business while it is building and to feel responsible for a piece of whether it succeeds.
That is something worth documenting.