DEV Community: Ladipo Samuel

What I Learned Working With Microsoft, SQUAD(GTCO), and Different Tech Communities

Ladipo Samuel — Sat, 23 May 2026 14:44:25 +0000

Starting at Microsoft, my first real professional experience outside gigs and contract work, I honestly thought working would still feel mostly individual. I was used to building alone, submitting work alone, and reporting whenever I wanted. But the moment I stepped out of the elevator onto the 8th floor, things already felt different.

There were coordinators, senior engineers, other interns, and an environment built around collaboration. It was new to me, but one thing that has always helped me is adaptability. I adjust quickly, and that helped me settle into the environment faster.

During the internship, we were given Python assessments. Since Python was one of the first languages I learned, I was able to complete mine quickly. But instead of stopping there, I started helping others. To me, it felt normal. I genuinely enjoyed helping people understand things. What I did not realize at the time was that in professional environments, people are always observing how you work, collaborate, and contribute beyond assigned tasks.

And yes, people are watching.

After the assessments, we were asked to select a lead intern, and I was chosen. That experience changed a lot for me because Microsoft introduced me to leadership in a practical way. Leadership was no longer just about being technically good. It became about responsibility and accountability.

It meant making sure people returned after breaks, checking if teammates got home safely, helping people stay on track, and ensuring the team functioned properly. Small things, but they shaped me deeply.

One of the biggest lessons I learned there was the importance of teamwork and building meaningful connections. These are words people hear often, but many do not fully understand how much they matter.

In every strong team, collaboration is critical. You need to be willing to contribute even when nobody asks you to. Sometimes, that means taking ownership of tasks others avoid. Sometimes, it means helping teammates, communicating updates clearly, or supporting the team even when you are not the official leader.

A lot of organizations evaluate people beyond technical ability. One major thing they observe is how well you contribute within a team environment.

The second lesson was building connections. Tech moves fast, and life is unpredictable. You never truly know who you might work with again in the future. Make meaningful connections beyond just “Hi” and “Hello.” Some of the best collaborations and opportunities I have had come from relationships built years ago. Even today, some of the strongest connections I made at Microsoft are still people I build and ship projects with.

Earlier, I mentioned that people are always watching. At the end of the internship, I found out just how true that was. Without realizing it, I was being observed based on how I adapted to feedback, supported people, communicated, and collaborated. That eventually led to me receiving the Excellence and Collaboration Award at the end of the internship.

After Microsoft, I thought I had learned a lot until I joined Squad by GTCO.

Although both environments were professional, Squad felt far more intense. There were multiple meetings, retrospectives, HR processes, standups, and tighter operational structures. It felt overwhelming initially, but it taught me lessons that shaped my professional mindset even further.

The first major lesson was ownership.

In meetings and retrospectives, everyone had to explain what they worked on, what challenges they faced, and how they approached solutions. Speaking in rooms filled with experienced professionals can feel intimidating, especially early on. But I learned that confidence matters a lot.

When you are unsure of yourself, people notice it immediately. Rushing through explanations just to escape attention creates poor communication. Instead, I learned to slow down, structure my thoughts properly, and confidently explain my work.

Taking ownership means standing behind your contributions confidently, even while learning.

Another major lesson was communication and reliability.

One thing many people underestimate in professional environments is communication. Teams cannot read your mind. Work can absolutely become overwhelming, but the way you communicate during difficult moments matters a lot.

I learned the importance of updating teams properly, communicating blockers early, asking for help when necessary, and being transparent about timelines. Communication builds trust, and trust becomes one of the strongest things people can say about you professionally.

Hearing someone say, “I trust this person,” is powerful.

But trust is not built in one day. It comes from consistency, accountability, adapting to feedback properly, meeting deadlines, and maintaining communication even when things become difficult.

Another important lesson I learned was contributing ideas confidently. Even if others are quiet, continue bringing value to the table. Suggest improvements, think critically, and participate actively. Good teams value contributors, not spectators.

Finally, after working across companies, communities, and multiple projects, one thing I strongly believe is this: impact creates value.

The people who stand out are usually the ones solving problems, helping others, contributing consistently, and stepping into difficult situations instead of avoiding them.

Being dynamic also matters. Do not place yourself inside one small box. Learn broadly, adapt quickly, and stay open to growth.

Over the past four years in tech, working across more than five companies and over 30 projects, these lessons have come from real experiences, mistakes, feedback sessions, difficult conversations, and constant improvement.

Not every feedback I received was positive, but one thing that helped my growth was refusing to let criticism discourage me. Instead, I focused on improving visibly over time. Managers, HR teams, PMs, and teammates notice growth when it is consistent.

And honestly, that consistency has opened doors for me through referrals, opportunities, collaborations, and trust.

If there’s one thing I’ve learned, it’s this: growth becomes inevitable when you stay consistent, adaptable, collaborative, and willing to improve.

The Strategy Behind Winning Hackathons

Ladipo Samuel — Sun, 17 May 2026 17:34:31 +0000

Hackathons happen almost every month, and there is always a winner. But here’s something most people don’t realize: the winner is not always the “best” participant technically.

I’ve participated in about 15 hackathons and won 12 of them. Looking back, I won’t say I was the best builder in every single one, but I approached them strategically. This write-up is based on both my wins and losses, and it covers practical things that genuinely increase your chances of winning a hackathon.

The first thing to understand is that every hackathon has a theme. Whether it’s Web2, Web3, fintech, healthtech, AI, or any other niche, there is always a direction the organizers want participants to build around. Inside that theme are usually sub-themes like using a specific API, solving a financial problem, building for healthcare, accessibility, education, and so on. Sometimes these details are released late, but they always matter.

One of the biggest mistakes participants make is building something impressive that does not align properly with the hackathon’s goals. No matter how good your product is, if it does not fit the problem statement, judges will struggle to connect with it. So the first rule is simple: read the overview properly and fully understand what the organizers actually want.

The next factor, and honestly one of the strongest winning factors, is team formation. Every hackathon I’ve won had a very strong team behind it. A good team pushes everyone beyond their limits.

A proper hackathon team is not just about having smart people. It’s about balance. You need people who can cover different parts of the product effectively. Usually, this means having a strong frontend developer, backend developer, product-minded thinker, and most importantly, a solid pitch person.

As someone who has also judged hackathons, I can confidently say that pitching can make or break a project. A lot of amazing products lose because they were poorly presented. Your pitch person should be able to explain the product clearly, confidently, and in a way that makes judges understand the value immediately. Pitching is not about shouting or overhyping a project. It’s about communicating properly. A strong team with strong pitching skills can increase your winning chances massively.

Another underrated strategy is researching the judges. Who are they? What kind of products do they work on? What problems are they interested in solving? Understanding this helps you position your solution in a way they can easily relate to.

Research plays a huge role in hackathon success. Check past winning projects, study the judging criteria, and gather as much information as possible before the event starts. Preparation gives you an advantage most teams ignore.

Then comes the build itself. Even if you do everything else correctly, a poor demo can destroy your chances. In hackathons, technical execution matters a lot. If your demo breaks during pitching, it affects confidence in the product.

Before presenting, test everything multiple times. Make sure the core features work properly and always prepare a backup plan, whether it’s a demo video, screenshots, or fallback environments. Knowing your product works smoothly gives you confidence while presenting.

Outside of winning, another important thing is networking. Some of the best opportunities from hackathons come from the people you meet. Your future co-founder, teammate, collaborator, or even employer might be in the same room. So even if you don’t win, connecting with people and confidently sharing your skills is still a huge win.

At the end of the day, hackathons are not just about prizes. They help you improve your speed, teamwork, communication, problem-solving, and execution. Keep building, keep shipping, and even if your idea feels common, add something unique that makes people remember it.

I’m rooting for every builder out there. Good luck, and don’t forget to pray for grace too.

The adrenaline of a new month: Merlin!

Ladipo Samuel — Fri, 01 May 2026 18:05:52 +0000

“I want to earn $10B every second this month. I want to build Jumia in 3 hours… MERLINNNN!”

Now, if that energy could actually be sustained 24 hours a day for the entire month, maybe it works. But you’re not a robot, so let’s be real about it.

We have 31 days this month. That’s a lot of time to achieve meaningful progress, but still not enough to do everything at once. Habits don’t form in a day, and hobbies don’t stick in 3 hours. If you want to be productive, consistency in the right direction is what matters. This applies to developers and honestly anyone trying to get better at something.

In April, I tried this approach, almost all of it. What stood out was that no matter how tough some days were, I showed up about 99% of the time. That alone made a difference. It’s not easy, and if you want to reach a new level, it won’t come from scrolling all day. It comes from intentional effort and some level of planning.

A lot of people will tell you to create a timetable. Then you pack everything into it. Day one, you’re fully energized. Day two, still going. By day three, reality starts to hit. The plan is too heavy. It becomes overwhelming, then procrastination sets in. Before you know it, the month is gone and you’re relating a little too much to “successfully wasted the month.” It sounds like a joke, but it’s real for a lot of people.

So what actually works? Start doing. Start small but be intentional. Set a plan you’re sure you can follow. Not something that looks impressive, but something realistic. Let each day end with you doing or learning something, no matter how small. After a week, adjust slightly. Add just a little more. Build gradually.

You might not do something huge by the end of the month, but you would have made real progress. And that counts.

Some days, you won’t feel like doing anything. That’s normal. Rest if you need to, but don’t abandon the plan. Keep it simple enough that you can always return to it.

Rooting for you this month. You can do more than you think, just start small and stay consistent.

Cencori: A Serverless Infrastructure Layer for Secure and Scalable AI Applications

Ladipo Samuel — Thu, 30 Apr 2026 16:32:17 +0000

Abstract

The rapid adoption of large language models (LLMs) has accelerated the development of intelligent applications across domains such as healthcare, finance, and customer service. However, building production-grade AI systems remains a complex engineering challenge due to fragmented tooling, security vulnerabilities, and the operational overhead of orchestrating multi-model workflows. This paper presents Cencori, a serverless infrastructure layer designed to unify model routing, persistent memory, agent orchestration, and security enforcement within a single backend platform. Unlike existing solutions that address these concerns in isolation, Cencori integrates them at the infrastructure level, enabling developers to build reliable and scalable AI systems with reduced complexity. We analyze the system architecture of Cencori, evaluate its core components, and position it within the broader AI tooling ecosystem. Our findings suggest that infrastructure-centric approaches significantly improve system robustness, developer productivity, and security in modern AI applications.

I. Introduction

Large language models (LLMs) have evolved from experimental research artifacts into foundational components of modern software systems. Their ability to generate, reason, and interact using natural language has enabled a new class of applications, including conversational agents, automated decision systems, and intelligent assistants.

Despite this progress, deploying LLM-based systems in production introduces significant challenges. Real-world AI applications are not composed of isolated model calls; rather, they operate as distributed systems requiring reliability, scalability, and security. Developers must manage multiple model providers, handle latency and failure scenarios, maintain conversational context, and protect systems against vulnerabilities such as prompt injection and data leakage.

Current development practices rely on a combination of independent tools: model routers, orchestration frameworks, vector databases, and security filters. While effective in isolation, these tools collectively increase system complexity and operational overhead.

Cencori addresses this fragmentation by introducing a unified infrastructure layer for AI systems. It abstracts core concerns such as routing, memory, orchestration, and security into a single platform, enabling developers to focus on application logic rather than system integration.

This paper presents the design and architecture of Cencori, evaluates its capabilities, and discusses its implications for building production-grade AI systems.

II. Background and Related Work

The ecosystem of AI development tools can be broadly categorized into three areas: model access layers, orchestration frameworks, and frontend integration tools.

Model access platforms provide unified interfaces for interacting with multiple LLM providers, enabling flexibility and redundancy. However, they are typically limited to request forwarding and lack deeper integration with application state or workflow logic.

Orchestration frameworks enable developers to chain model calls and construct multi-step workflows. While powerful, these frameworks often require extensive configuration and do not inherently address system reliability or security concerns.

Frontend-focused AI tools simplify the integration of AI into user interfaces but depend heavily on backend systems that developers must implement separately.

Existing research has also highlighted emerging risks in LLM systems, particularly prompt injection attacks and data leakage [1], [2]. These challenges underscore the need for infrastructure-level solutions that incorporate security by design.

Cencori differentiates itself by combining routing, memory, orchestration, and security into a unified backend abstraction. This approach aligns with principles from distributed systems design, where complexity is managed through layered architectures and well-defined interfaces.

III. System Architecture
A. Architectural Overview

Cencori adopts a layered architecture that separates concerns while maintaining tight integration between system components. The overall structure is illustrated as follows:

Client Applications (Web, Mobile, APIs)
↓
Unified API Gateway
↓
Intelligent Routing Engine
↓
Multi-Provider LLM Layer
↓
Memory and State Management
↓
Security and Policy Enforcement

This architecture enables modularity while ensuring that critical functions such as routing and security are consistently applied across all interactions.

B. Core Components
1) API Gateway

The API gateway serves as the primary interface between client applications and the platform. It is designed to be compatible with widely adopted APIs, allowing developers to integrate Cencori with minimal changes to existing systems.

2) Routing Engine

The routing engine dynamically selects LLM providers based on factors such as latency, cost, and availability. It supports fallback mechanisms, ensuring continuity of service in the event of provider failure.

This dynamic selection process improves system resilience and enables cost-performance optimization at runtime.

3) Memory Layer

Cencori incorporates a persistent memory system that allows applications to maintain context across interactions. This transforms inherently stateless model interactions into stateful experiences, improving coherence and usability in conversational systems.

4) Security Layer

Security is integrated directly into the infrastructure. The platform includes mechanisms for prompt injection detection, PII redaction, and input/output validation.

By embedding these protections within the request pipeline, Cencori reduces the likelihood of vulnerabilities and ensures consistent enforcement across applications.

5) Agent Orchestration

Cencori supports the construction of multi-step workflows through agent orchestration. This enables developers to define structured processes involving multiple model interactions, external tools, and conditional logic.

IV. Key Features

Cencori’s design emphasizes the integration of multiple capabilities into a cohesive system.

A. Dynamic Model Routing

The platform enables seamless switching between model providers, improving reliability and enabling fault tolerance in distributed environments.

B. Persistent Context Management

The memory layer supports context retention across sessions, allowing applications to deliver more coherent and personalized interactions.

C. Integrated Security Mechanisms

Built-in protections ensure that applications are safeguarded against common vulnerabilities without requiring additional implementation effort.

D. Workflow Automation

Agent orchestration enables the development of complex AI systems that go beyond simple prompt-response interactions.

V. Implementation and Integration

Cencori is designed for ease of adoption. Its compatibility with existing APIs allows developers to integrate the platform by modifying configuration parameters rather than rewriting codebases.

The serverless architecture eliminates the need for infrastructure management, enabling automatic scaling and reducing operational overhead. This design aligns with modern cloud-native development practices and supports rapid deployment of AI applications.

VI. Applications

Cencori’s capabilities make it suitable for a wide range of applications:

Conversational AI systems with persistent memory
Healthcare applications requiring secure data handling
Financial systems leveraging AI for analysis and automation
Customer support platforms handling complex, multi-step queries

In each case, the platform enhances reliability, scalability, and security.

VII. Evaluation
A. Advantages

Cencori offers several benefits:

Reduced architectural complexity through unified infrastructure
Improved reliability via dynamic routing and failover mechanisms
Enhanced security through integrated protections
Scalability enabled by serverless design B. Limitations

Despite its advantages, certain limitations remain:

Dependence on a centralized platform introduces vendor lock-in
Abstraction may limit low-level customization
Usage-based pricing models require cost monitoring at scale

VIII. Future Work

Future developments may include:

Support for multimodal AI systems
Edge deployment for latency-sensitive applications
Advanced routing strategies driven by real-time metrics
Integration with model training and fine-tuning pipelines

IX. Conclusion

The development of AI applications is increasingly defined by system-level challenges rather than model capabilities alone. Cencori addresses this shift by introducing a unified infrastructure layer that integrates routing, memory, orchestration, and security.

By abstracting these concerns, the platform reduces development complexity while improving system reliability and scalability. As AI systems continue to evolve, infrastructure-driven approaches such as Cencori are likely to play a critical role in enabling robust and production-ready applications.

Am I Really in Tech or Just Learning Languages?

Ladipo Samuel — Fri, 17 Apr 2026 14:16:19 +0000

Am I really in tech or not?

Honestly, there’s no “in between” in tech. You are either building, learning, or you are just… watching from the sidelines.

A lot of people quietly struggle with this question. What actually qualifies someone as a developer? Do I need 10 languages? A big job title? A fancy GitHub?

Let’s clear that up.

To be in tech simply means you are specialized in a direction and actively building within it. Even systems that look like they “know everything” are still built on deep specialization under the hood.

Now the real confusion usually starts here:

“Is Python enough to call myself a developer?”
“Do I need TypeScript, Go, Rust, Java, and maybe one alien language?”

The honest answer is yes… Python is enough. TypeScript is enough. But not in the way most people think.

And this is where people start entering what I call the “language hopping loop” 😄

You learn Python.
You build a few projects.
Then someone says “JavaScript is where the jobs are.”
You switch.
Then another person says “Go is better for scalability.”
You switch again.

At that point, you are not learning deeper systems anymore, you are basically doing load balancing… but for your attention span 😭

And the result?

You might even land interviews, but when they ask deeper questions like system design, caching strategies, or how your API handles concurrency, things start feeling… blurry.

Because the issue was never the language.

There is no “best language”. There is only context.

Python is not better than TypeScript. TypeScript is not better than Python. They are just tools optimized for different workloads, like how caching, indexing, and database choice depend on the system you are building.

So how do you actually get into tech properly?

Not the usual “learn a language, build a todo app, become senior engineer in 2 weeks” story 😄

The real path is deeper than that.

Start with a language. Yes.
But don’t stay at surface level.

Go beyond syntax:

understand how memory is managed
learn how APIs actually handle requests under the hood
explore scalability concepts like load balancing and caching
break things, fix them, rebuild them better

Think of it like mathematics.

You don’t stop at BODMAS and call it a day. You move into algebra, calculus, and eventually deeper problem solving where everything connects.

Tech is the same.

Once you pick a path, start building real things. Then revisit them as your knowledge grows. Improve the architecture. Refactor the design. Optimize performance. That is where growth actually happens.

And over time, something interesting happens.

You stop saying “I know Python” and start saying “I understand systems.”

That shift is what I like to call the transition from learning mode to improvement mode.

It’s a bit like solo leveling 😄

And here’s the final truth:

Once you deeply understand one stack, moving to another becomes easier. Not because it is similar, but because your thinking has already adapted to complexity.

That’s when you are truly in tech.

Not because you know everything, but because you know how to learn anything.

Every week, I will be sharing more of these, focused on practical technical growth, deeper understanding of systems, and lessons that actually help you become a better builder in tech.

If you’re on the same journey, stick around. There’s more coming!!!

Testing API Security with Cencori: A Case Study Using InsecurePay

Ladipo Samuel — Fri, 03 Apr 2026 19:25:10 +0000

Before running any security scans, I needed something meaningful to test. So I built InsecurePay, a simple payment API designed to mirror real-world payment systems, but intentionally implemented with relaxed security.

At its core, InsecurePay handles three main functions:

Authentication — a basic login endpoint that returns a token
Payments — an endpoint that processes card payments
Transactions — an endpoint to view processed payments

The project is built with Node.js and Express, and it follows a structure that reflects many real backend systems:

Routes handle incoming requests
Controllers manage the business logic
A mock database simulates data storage

How InsecurePay Works

When a user sends a payment request, the API:

Accepts card details and payment information
Simulates processing (no real payment gateway is used)
Stores the transaction
Returns a response containing the transaction details

At first glance, everything works as expected. You can log in, make a payment, and receive a successful response.

However, despite being functional, the API had some serious security concerns:

Sensitive data like card numbers and CVV were exposed in responses
Secrets were hardcoded directly into the codebase
Critical routes, such as payments, lacked proper protection
Logging exposed more information than necessary

None of these issues broke the application, but they violated basic security expectations. That was intentional.

InsecurePay wasn’t designed to be perfect. It was built to reflect real-world flaws so they could be identified and addressed.

At this point, I had a working API, but I already knew it wasn’t secure. So I decided to test it using Cencori Scan, an AI-powered tool that detects security issues in codebases and suggests fixes. It can identify hardcoded secrets such as API keys and passwords, flag PII leaks like emails and card details, and detect vulnerable routes and unsafe coding practices.

The goal was simple: could this tool detect real vulnerabilities in my project, and more importantly, help fix them?

I ran the scan using:

npx @cencori/scan

Results from the Scan

Cencori flagged several critical issues:

Secrets in code — API keys and passwords were hardcoded
PII exposure — card numbers, CVV, and emails were returned in responses
Unprotected routes — sensitive endpoints lacked proper authorization checks
Unsafe logging — request payloads exposed sensitive information

While nothing broke, the security posture of the application was clearly weak.

Fixing the Issues with Cencori

I enabled Cencori’s auto-fix feature to address the problems more efficiently. To use Cencori Scan, you follow these steps:

Step 1: Get an API key

I generated a free API key from the dashboard and added it to my environment:

$env:CENCORI_API_KEY="your_api_key_here"

Step 2: Run auto-fix

npx @cencori/scan --fix

Cencori then analyzed each issue, suggested fixes, and updated parts of the code automatically.

What Changed?

After reviewing the results, I made several important improvements:

Moved secrets out of the codebase
Added token-based protection to secure sensitive routes
Removed sensitive fields such as card numbers and CVV from API responses
Cleaned up unsafe logging practices

Some fixes were applied automatically, while others required careful review and manual adjustments, which is expected when working with security-critical systems.

If you’re a developer who relies on AI to generate or automate parts of your code, tools like this become even more important. Cencori helps ensure that what gets produced isn’t just functional, but also secure. It acts as a safety layer, catching issues like exposed secrets, data leaks, and weak access controls before they make it into production.

In a world where speed is becoming easier with AI, security should not be an afterthought. Cencori helps you maintain that balance between building fast and building safely.

You can test it in your own project here:
https://cencori.com/

You can also explore the InsecurePay project here:
https://github.com/ladicodes/InsecurePay-API