<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Oluwaseyi Kodeleyiri</title>
    <description>The latest articles on DEV Community by Oluwaseyi Kodeleyiri (@oluwaseyivibex).</description>
    <link>https://dev.to/oluwaseyivibex</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1813274%2Fb7f90d30-6460-4f20-8625-4caa251df835.jpeg</url>
      <title>DEV Community: Oluwaseyi Kodeleyiri</title>
      <link>https://dev.to/oluwaseyivibex</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/oluwaseyivibex"/>
    <language>en</language>
    <item>
      <title>The ceiling is way higher.</title>
      <dc:creator>Oluwaseyi Kodeleyiri</dc:creator>
      <pubDate>Wed, 15 Jul 2026 01:59:01 +0000</pubDate>
      <link>https://dev.to/oluwaseyivibex/the-ceiling-is-way-higher-5hb2</link>
      <guid>https://dev.to/oluwaseyivibex/the-ceiling-is-way-higher-5hb2</guid>
      <description>&lt;p&gt;Coming from a school where 80% of the students, even the computer science ones, were straight up computer illiterate. I had the drive, I knew I wanted this, but the standard around me was so low I genuinely didn't know how far I could take software engineering until much later.&lt;/p&gt;

&lt;p&gt;I look at some of these Unilag tech guys now and there's this specific kind of envy. Not "I wish I had their opportunities" envy. More like, I wish I had people to look up to where I was. People whose work I could stumble on and go "wait, this is insane, how do I get here."&lt;br&gt;
Because that's what a good environment actually gives you. Not talent, not shortcuts. A ceiling you can see past. When almost nobody around you is pushing past the basics, "good" becomes whatever the room accepts. You don't know you're underselling yourself because there's no one there to show you otherwise.&lt;/p&gt;

&lt;p&gt;I built what I know without that. No senior dev down the hall, no cohort of people shipping insane side projects to compare notes with. Just me, figuring out on my own what "far" was supposed to look like, usually by finding it online months or years after someone else already knew.&lt;/p&gt;

&lt;p&gt;I'm not writing this for sympathy. I'm writing it because I think there are a lot of people who went to schools like mine, who had the drive too, and just never found out how big the ceiling actually was. If that's you, the ceiling is way higher than your school ever showed you. Go find it.&lt;/p&gt;

</description>
      <category>productivity</category>
      <category>programming</category>
      <category>career</category>
      <category>software</category>
    </item>
    <item>
      <title>Cash Flow Mistakes SMEs Make (Part 1/2)</title>
      <dc:creator>Oluwaseyi Kodeleyiri</dc:creator>
      <pubDate>Mon, 13 Jul 2026 18:03:57 +0000</pubDate>
      <link>https://dev.to/oluwaseyivibex/cash-flow-mistakes-smes-make-part-12-1m5d</link>
      <guid>https://dev.to/oluwaseyivibex/cash-flow-mistakes-smes-make-part-12-1m5d</guid>
      <description>&lt;p&gt;Ask any Nigerian SME owner how business is going, and you'll often hear the same confusing answer: "Sales are good, but I don't know where the money goes." It's one of the strangest puzzles in small business — a shop can be busy, the books can show a profit on paper, and the owner can still struggle to pay rent at the end of the month.&lt;/p&gt;

&lt;p&gt;The truth is that profit and cash are not the same thing, and most SMEs don't fail because they aren't making money. They fail because the money isn't there when it's needed. Cash flow, not profitability, is what keeps the lights on — and it's also where most small business owners quietly bleed themselves dry through habits that feel harmless in the moment.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;strong&gt;The wallet with no walls&lt;/strong&gt;
&lt;/h2&gt;

&lt;p&gt;The most common mistake is also the easiest to fall into: treating the business account like a personal wallet. Rent, school fees, a "quick loan" to a relative — it all comes out of the same pot as supplier payments and staff salaries. There's no wall between the business and the owner's personal life.&lt;/p&gt;

&lt;p&gt;This isn't just messy bookkeeping. It erases the ability to answer a basic question — is the business actually healthy? — and it's often the exact reason banks and investors turn SMEs away later. A business with no clean financial history is a business nobody wants to lend to.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;strong&gt;Mistaking revenue for money you can spend&lt;/strong&gt;
&lt;/h2&gt;

&lt;p&gt;A related trap is seeing ₦2 million land in the account and treating all of it as spendable. But that number already has obligations attached — cost of goods, pending supplier invoices, taxes — that haven't been subtracted yet. Cash sitting in an account isn't the same as cash that belongs to the owner. Spend against revenue instead of profit, and the shortfall only becomes visible when a bill comes due and the money simply isn't there.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;strong&gt;The debt nobody's tracking&lt;/strong&gt;
&lt;/h2&gt;

&lt;p&gt;Credit sales are a fact of life in Nigerian retail and wholesale — goods handed over on trust, to be paid for later. The trouble is how that trust gets recorded: a notebook, a WhatsApp thread, or nothing more than memory. Debts get forgotten, disputed, or drag on for months, while the business still has to pay its own suppliers on time regardless of who owes it what. A business can be sitting on substantial receivables and still run out of cash, simply because none of that money has actually arrived yet.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;strong&gt;Cash locked in stock&lt;/strong&gt;
&lt;/h2&gt;

&lt;p&gt;Inventory is cash — it's just wearing a different costume. Overstock, and money sits on a shelf instead of in an account. Understock, and the business misses its busiest weeks because cash went elsewhere and there was nothing left to restock with. Few owners think of inventory this way, but every unsold item is a naira that isn't available for anything else.&lt;/p&gt;

&lt;h2&gt;
  
  
  &lt;strong&gt;Living in today, not looking ahead&lt;/strong&gt;
&lt;/h2&gt;

&lt;p&gt;Most SMEs manage cash flow reactively — checking today's balance and reacting to whatever it says. Almost none forecast two to four weeks out. That's how a known, predictable expense like rent still manages to arrive as a surprise: it was always coming, but nobody was tracking it against what was expected to come in before then. Forecasting doesn't require sophistication. It requires simply writing down what's due and what's expected, and checking the gap before it becomes a crisis.&lt;/p&gt;

&lt;p&gt;Part 2 covers the other 5 — including the pricing mistake that makes a business look profitable while cash quietly drains, and the one liquidity mistake unique to how Nigerian merchants move money today.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>sme</category>
      <category>productivity</category>
      <category>discuss</category>
    </item>
    <item>
      <title>If you're a software developer just starting out and you've ever wondered how senior devs think while they build, this is for you.</title>
      <dc:creator>Oluwaseyi Kodeleyiri</dc:creator>
      <pubDate>Tue, 16 Jun 2026 03:08:21 +0000</pubDate>
      <link>https://dev.to/oluwaseyivibex/if-youre-a-software-developer-just-starting-out-and-youve-ever-wondered-how-senior-devs-think-2m9d</link>
      <guid>https://dev.to/oluwaseyivibex/if-youre-a-software-developer-just-starting-out-and-youve-ever-wondered-how-senior-devs-think-2m9d</guid>
      <description>&lt;p&gt;A junior dev asked me something recently that actually made me think. He said: "As a software developer or vibe coder, while you're building, what do you usually look out for before moving to production? If you can give me something like a framework or blueprint, it would really help me while I build so I can avoid basic mistakes."&lt;/p&gt;

&lt;p&gt;My first answer was simple: understand the &lt;strong&gt;&lt;em&gt;basics&lt;/em&gt;&lt;/strong&gt; and &lt;strong&gt;&lt;em&gt;fundamentals&lt;/em&gt;&lt;/strong&gt; of the programming language you're using. Then the tools and libraries on top of that. Even if you are a vibe coder, this still applies to you. You can't debug what you don't understand. and you can't secure what you don't know exists.&lt;/p&gt;

&lt;p&gt;But the question deserved more than that. So here's the full answer.&lt;/p&gt;




&lt;h2&gt;
  
  
  First, your code
&lt;/h2&gt;

&lt;p&gt;Before you do anything else, look at your code like a stranger would.&lt;/p&gt;

&lt;p&gt;If you are a vibe coder, &lt;strong&gt;READ THE CODE!&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Are there API keys or passwords written directly in it? It will bite you &lt;strong&gt;HARD!&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;Are you handling errors? Every time you fetch data from an API, every time you wait for something async, every time a user types something into a field, assume it will fail. What does your app show when it does? If the answer is "a blank screen" or "nothing," that's a bug.&lt;/p&gt;

&lt;p&gt;Also, remove your &lt;code&gt;console.log&lt;/code&gt; statements. it's fine if you are still in development stage, abeg not in production.&lt;/p&gt;




&lt;h2&gt;
  
  
  Second, your data
&lt;/h2&gt;

&lt;p&gt;If users are sending data to your server, you validate it on the server. Not just in the browser, &lt;em&gt;on the server!.&lt;/em&gt; Frontend validation is for user experience. Backend validation is for security. Someone can bypass your frontend in about 30 seconds.&lt;/p&gt;

&lt;p&gt;Never trust what a user sends you. Treat every input like it was typed by someone trying to break your app, because eventually, someone will. Check it. Don't just pass it straight into your database.&lt;/p&gt;

&lt;p&gt;Also check your database queries. Are you accidentally fetching thousands of rows when you only need ten? Are you running a query every time someone presses a key? Small things like this slow your app down quietly, and you won't notice until it's under real load.&lt;/p&gt;




&lt;h2&gt;
  
  
  Third, auth and security
&lt;/h2&gt;

&lt;p&gt;There are two things that feel similar but are completely different: authentication (are you who you say you are?) and authorization (are you allowed to do this?).&lt;/p&gt;

&lt;p&gt;A lot of developers only think about authentication. They make sure users are logged in, and they stop there. But if a logged-in user can view another user's data just by changing a number in the URL, there will be problem ohh my brother 😂. &lt;br&gt;
Sensitive endpoints like login, password reset, e.t.c. should have rate limits so no one can hammer them with thousands of attempts. CORS should be locked down to specific domains in production, not set to &lt;code&gt;*&lt;/code&gt; (which means "everyone").&lt;/p&gt;




&lt;h2&gt;
  
  
  Fourth, does your product actually work?
&lt;/h2&gt;

&lt;p&gt;Ngl this sounds obvious but it gets ignored more than you'd think.&lt;/p&gt;

&lt;p&gt;Go through your app like a new user would.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Think through every scenario you can.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;What happens if a user fills in the form but leaves one field empty? What if they paste 10,000 characters into a text box that's supposed to hold a name? What if they click the submit button twice really fast? What if they go back after submitting? What if they close the tab halfway through a payment, then come back. Are they charged twice? What if they upload a file that's 500MB when you expected 2MB? What if they use your app on slow 3G and the request times out mid-action?&lt;/p&gt;

&lt;p&gt;These aren't just any cases. These are regular use cases. Real users do all of this, not to be malicious but because people just use things differently than you expect. (Not everyone is as smart as you are)&lt;/p&gt;

&lt;p&gt;Every time you build a feature, form a habit of asking yourself what happens if a user does this or that, or doesn't do this or that. You won't catch everything, but you'll catch a lot.&lt;/p&gt;

&lt;p&gt;I'm just going to drop this here, i think this post is getting too long. Loading states and error messages aren't nice to haves. They're part of the product. If your app freezes silently when something goes wrong, users won't think "there's a bug." like you, they'll think your product doesn't work. Which takes us to the fisth.&lt;/p&gt;




&lt;h2&gt;
  
  
  Fifth, your infrastructure
&lt;/h2&gt;

&lt;p&gt;The most common "works on my machine" failure in production is environment variables not being set correctly. Your app works locally because your &lt;code&gt;.env&lt;/code&gt; file is there. On the server, it might not be. Double check.&lt;/p&gt;

&lt;p&gt;You also need logging. Once you ship, you need a way to know when things break before your users have to tell you.&lt;/p&gt;

&lt;p&gt;And run your build before you push your code especially if you are collaborating with other devs (make dem no go sw**r for you 😂). Make sure it compiles cleanly. Warnings you've been ignoring locally sometimes become errors in a different environment.&lt;/p&gt;




&lt;h2&gt;
  
  
  Sixth, your users
&lt;/h2&gt;

&lt;p&gt;Does your app work on mobile? If you built a web app and only tested it on your laptop, open it on your phone right now. You might be surprised.&lt;/p&gt;

&lt;p&gt;Is it fast? Not fast on your machine with nothing else running, fast for someone on a mid-range android phone (android users abeg no come for me 👀) on a decent connection. Compress your images. Don't load things you don't need yet. These things matters too.&lt;/p&gt;




&lt;h2&gt;
  
  
  The &lt;strong&gt;order&lt;/strong&gt; to &lt;strong&gt;remember&lt;/strong&gt; before you press &lt;strong&gt;enter&lt;/strong&gt; (hehe you get the rhyme?😂)
&lt;/h2&gt;

&lt;p&gt;Code → Data → Auth &amp;amp; Security → Product behavior → Infrastructure → User experience.&lt;/p&gt;

&lt;p&gt;Each layer depends on the one before it. You can have a beautiful UI and still ship rubbish if you skipped layer two or three.&lt;/p&gt;

&lt;p&gt;You don't have to be perfect before you ship. But you should be able to say you thought through each of these, including the "what ifs." &lt;/p&gt;

&lt;p&gt;I know i have not said all, but as you move on and gain more experience you get to understand better.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>productivity</category>
      <category>beginners</category>
      <category>software</category>
    </item>
  </channel>
</rss>
