From economics to code: how I became a software engineer

In this article13 sections

1. Why I decided to become a software engineer
2. What economics gave me that a coding course did not
3. My first 12 months: how I actually learned
4. My first clients and my first expensive mistakes
5. From websites to systems: how the work grew
6. Working with global teams: Google, Andela, SGO Group and SIDCO
7. From writing code to leading a team at Xoftpro Smart Systems
8. How to become a software engineer without a computer science degree: a 12-month plan
9. Mistakes I made that you can skip
10. Advice for career switchers: accountants, teachers, bankers and others
11. Key takeaways
12. Frequently asked questions
13. Next step: turn your idea into a working system

I did not plan to become a software engineer. I planned to become an economist, or maybe a banker, or maybe “something in government”. I sat in lecture halls in Nigeria and learned about supply, demand and opportunity cost, and I believed a good degree would open a door. Then I graduated, and the door was a queue. Hundreds of graduates, one vacancy, and a line on every advert that said “two years experience required”. That was the year I started asking a different question: how do you become a software engineer when nobody ever taught you to code?

I am Dan Audu. Today I am a software engineer and business technology consultant in Abuja, and the CTO and team lead at Xoftpro Smart Systems. I have spent about eight years building websites, CRM and ERP systems, mobile apps, POS software, AI automation, CCTV and office networks, and I have worked with teams at Google, Andela, SGO Group in Israel and SIDCO in Greece. But I did not start there. I started with a degree in economics, a borrowed laptop, and a lot of doubt.

This is the full story, with the mistakes left in. I will tell you how I decided, what I learned in what order, what my first paid job taught me (mostly what not to do), how the work grew, and what I would tell any Nigerian graduate who wants the same road. If you are an accountant, a teacher, a pharmacist or a banker thinking about a career change, this is written for you. You will find a table of how economics helped me, a 12-month plan, a naira budget for learning and a list of mistakes I hope you avoid.

Why I decided to become a software engineer

People love to tell this story as if it was a bright moment: one day a light came on and I never looked back. That is not what happened. It was slow, and it started with frustration, not inspiration.

The job market I met

When I finished my degree, I did what most graduates do in Abuja and Lagos. I printed CVs. I visited offices. I filled online forms that never replied. I attended interviews where the panel had already picked a candidate and I was there to complete the numbers. I do not say this to complain. It is simply the market. The supply of graduates is far bigger than the supply of formal jobs, and an economist should have expected it. I certainly knew the theory of unemployment. It felt different when I was inside the graph.

What I noticed, while waiting, was that small businesses around me were struggling with problems that looked solvable. A shop owner kept his stock in an exercise book and lost track of what was missing. A school wrote results by hand and needed three weeks to print report cards. A restaurant owner could not tell which dish gave profit. Nobody was selling them a simple fix at a price they could afford. That gap stayed in my head.

The spark: a spreadsheet that did my work for me

Before I ever wrote proper code, I fell in love with spreadsheets. In my economics work I had to clean data, calculate averages and build small models. One weekend I discovered that a spreadsheet formula could do in ten seconds what I had been doing by hand in two hours. I remember sitting in front of that screen thinking, “Somebody should build this for every business.” Then a second thought arrived: “Why not me?”

From formulas I moved to small scripts that automated repeated tasks, and from scripts to the idea of a web page that other people could use. That progression, from a formula to a form to a website to a system, is how many self-taught developers start. Nobody gives you a certificate for it, but each step teaches you how to turn a repeated manual task into a machine.

The economist’s decision

When I finally decided to learn to code seriously, I did what my degree trained me to do: I made a decision using costs and benefits. Here is how it looked in my head.

• Cost of entry: low. A laptop, a data plan and time. No expensive lab, no licence, no permission from anyone.
• Cost of failure: low. If I failed after six months, I would still have a new skill and some projects, and I could go back to job hunting.
• Demand: high and growing. Businesses in Nigeria needed websites, systems and apps, and there were far fewer people who could build them well than there were people who wanted the work.
• Reach: global. Software can be built in Abuja and sold or delivered anywhere.
• Opportunity cost: the time I would have spent applying for jobs that never replied.

An economist would call this a positive expected return with limited downside. I called it “let me try for six months and see”. That decision, taken quietly in a small room without any fanfare, is the reason you are reading this now.

The doubts I had

I had many doubts, and I think it is healthy to name them. I feared I was too old to start, even though I was not. I feared that everyone else had studied computer science and I would always be behind. I worried that people would ask, “Why did you go to school for economics and now you write code?” I compared myself with friends who found bank jobs quickly and looked settled, while I sat at home with a laptop and a small dream. Some days I felt foolish.

What helped was to shrink the goal. I did not tell myself, “I will become a great engineer.” I told myself, “Today I will make this button work.” Big goals are heavy, but small tasks are easy to lift. After a few months, the pile of small wins looked like real progress, and the doubts became quieter. They never disappeared completely. Even today I meet a problem that makes me feel like a beginner. The difference is that I now know that the feeling passes when I keep working.

What economics gave me that a coding course did not

People ask me if my economics degree was a waste. It was not. It gave me a way of thinking that many developers learn late, or never. Coding tells you how to build a thing. Economics tells you whether the thing is worth building, for whom, and at what price. The table shows the ideas I use most often.

Opportunity cost, the most useful idea I own

The most useful idea from my degree is opportunity cost. Every client wants ten features, and every developer wants to build all of them. I have learned to say, “If we build this, we cannot build that in the same budget. Which one earns you more?” That single question has saved more projects than any tool. It moves the discussion from “I want” to “I choose”.

Incentives explain most software problems

When a shop’s stock system fails, the cause is rarely the code. It is usually an incentive problem. If a cashier finds that recording a sale in the system takes longer than writing it in a book, the cashier will use the book. If a manager can hide a discount by not entering it, some will. Good system design looks at people’s incentives as carefully as at database tables. I learned that from economics, not from a coding tutorial.

Measuring things that matter

Economics also trained me to ask “compared to what?” A report that says sales are ₦4,000,000 this month means nothing until you compare it with last month, with the same month last year, and with the cost of producing them. That habit now shapes how I build dashboards and reports for clients. I explain how to use your own numbers in my article on data analytics for SMEs.

My first 12 months: how I actually learned

I will be honest. I wasted time in the first three months, because I did not know what to learn or in what order. If I could give my younger self one gift, it would be a plan. So here is what I did, and then what I would do better.

The setup: cheap laptop, night data and NEPA

My first real machine was a used laptop with an old battery that held about forty minutes. I did much of my learning at night, when data bundles were cheaper and the house was quiet. I learned to download tutorials and documentation in the day, when I had a good connection, and to practise offline. I kept a power bank and a small charging routine because NEPA would take light at the worst moments. If you are in the same situation today, the good news is that you can start with less than you think. You do not need the latest MacBook. You need a working laptop, patience and a plan to keep the power on.

The order I learned things

After a lot of jumping around, I settled on an order that worked. First, HTML and CSS, which shape a web page. Then JavaScript, which makes it move and respond. Then PHP and MySQL, which let a website save and read data, and WordPress as a practical way to deliver real client sites. Then Git for saving versions, then APIs (ways for systems to talk to each other), then hosting and security. Only later did I add mobile apps and larger frameworks. If you want a full path, I wrote a step-by-step guide in learning to code in Nigeria: a realistic roadmap.

The rule that saved me: build for a real person

Tutorials taught me syntax. Real people taught me software. The moment I began building small things for real people, my learning doubled in speed. A simple booking page for a salon owner forced me to think about time slots and reminders. A stock sheet for a provision shop forced me to handle mistakes. A small results page for a school showed me that teachers would refuse any system that added work. None of those projects were big or beautiful. They were real, and reality is the best teacher I have had.

What my year looked like

Here is a cleaned-up version of my first year. In real life it was messier, but this is the shape.

My first clients and my first expensive mistakes

If you want to learn fast, get a paying client early. If you want to learn expensively, get a paying client without an agreement. I managed to do both.

The first paid project

My first paid job was a small website for a local business owner who wanted “something simple”. I agreed a price of roughly ₦30,000, and I was thrilled. I did not know that “simple” is the most dangerous word in software. After the first draft, the owner asked for a photo gallery, then an online booking form, then a page in another language, then a way to update prices from a phone. Each request was small. Together they doubled the work. I said yes to all of it because I was afraid of losing my first client. I finished weeks late, tired and barely paid for my data.

The free work trap

The second mistake was giving away work. I built “a quick demo” for people who never intended to buy. I spent evenings on layouts for a business owner who told me, after I sent it, that his nephew would “just copy it”. I learned to protect my time. Now I never start design work without a signed scope and a deposit. I explain this rule more fully in my article on how to price your work as a Nigerian freelancer or agency.

The client who did not pay

Another early lesson came from a project where I delivered the full system and waited for the last payment. I waited, and waited, and every reply was “I will send it tomorrow”. No contract, no stage payments, no leverage. I eventually recovered part of the money, but I learned that trust is not a payment plan. I now work with a simple deposit, milestone payments and a written handover. If you deal with difficult clients, you can read what I learned the hard way.

What fixed my business

Three simple habits turned things around. I wrote down the scope in plain words and asked the client to confirm by message. I took a deposit before starting. I said “this is a new request, here is the extra cost” without apology. Once I started doing these, my income rose and my stress fell, even though my skills had not changed overnight. The lesson is that a technical skill without a business habit is only half a career.

From websites to systems: how the work grew

I started with websites because they are the easiest thing to sell. Yet the more I built, the more I heard the same sentence: “Can it also do this for my business?” A restaurant owner wanted orders and stock. A school wanted results and fees. A real estate agent wanted to track leads and payments. Each request pushed me one step deeper into business software.

CRM and ERP

A CRM (customer relationship management system) keeps track of leads, customers and follow-ups. An ERP (enterprise resource planning system) joins sales, stock, purchases and accounts. Building these taught me more about real businesses than any classroom, because you cannot design a good system without asking uncomfortable questions such as “who approves this discount?” and “what happens when stock in the shop does not match stock in the system?”

POS, mobile apps and AI automation

From there I moved to point-of-sale software for restaurants, supermarkets and pharmacies, mobile apps for delivery and services, and AI automation that answers customers on WhatsApp or handles repeated tasks. Each new area rested on the same foundation: understand the money, understand the people, then write the code.

CCTV and networks: the unglamorous work that pays

Some of my most valuable jobs have nothing to do with code. Installing CCTV, planning an office network or setting up a backup system does not look impressive on social media, but businesses pay well for it because it protects them. Being able to offer both software and infrastructure means a client can call one person instead of four. That helps them, and it keeps my work steady.

Working with global teams: Google, Andela, SGO Group and SIDCO

Later in my career I worked with teams from Google, Andela, SGO Group in Israel and SIDCO in Greece. I will not describe any private details of those companies. What I can share is what I learned from watching serious teams work.

Process beats talent

The first thing that struck me was how much process mattered. Code was reviewed by another person before it went live. Tasks were written clearly. Meetings had an agenda and an end time. Decisions were recorded so that nobody had to remember what was said. In small Nigerian businesses we often trust memory and speed. On serious teams they trust habits. I brought those habits home, and they saved my own projects many times.

Clear writing is a technical skill

Working across time zones taught me to write clearly. A message like “the site is not working” wastes a day when the person reading it is asleep. A message like “the checkout page returns an error after step 3, here is a screenshot and the time it happened” saves the day. Since then I have trained my whole team to write like that, and our clients notice.

Not having a computer science degree was not a wall

I worried at first that I would feel out of place as an economist among engineers. Some moments were uncomfortable. Yet what mattered in the end was whether I could solve the problem in front of me and communicate well. My business background became a strength. I understood why a feature mattered to a client, and many engineers said that helped them. That is one reason I tell career switchers to keep their old experience close.

If you are interested in how Nigerian developers are trained and hired at a global level, I wrote about that in Andela and the rise of Nigerian tech talent.

From writing code to leading a team at Xoftpro Smart Systems

As the work grew, I could no longer build everything alone. I became CTO and team lead at Xoftpro Smart Systems, and my job changed. Instead of asking “how do I build this?” I began to ask “who should build this, and how will we know it works?”

The hardest change: letting go

Most developers who move into leadership struggle with the same thing. You are used to being the fastest person in the room. Suddenly you must let someone else write the code, and it will be slower and different from how you would do it. I had to learn to review, teach and trust. I still write code, but I keep my hands out of the parts where somebody else should grow.

How my week looks today

My days now follow a simple rhythm. Mornings are for deep work: design decisions, tricky code and anything that needs quiet. Midday is for calls with clients and the team. Afternoons are for reviewing work and answering questions. Fridays are for planning the next week and looking at numbers. I protect the first two hours of the morning because I learned that if I open messages first, the day belongs to other people. It is not a fancy system. It is a habit, repeated until it becomes automatic, and it is the same discipline I tried to build when I first taught myself to code.

Teaching what I wish I had been taught

I try to give my team the shortcuts I never had: a clear plan for learning, written standards, code review that is kind and specific, and honest conversations about pay and growth. Nigerian developers are talented, and they leave when they feel ignored. So I treat training as part of the job, not an extra.

Balancing quality and speed

Every client wants it fast, cheap and perfect. You cannot have all three. My job as a lead is to explain the trade-off with numbers and stories, not with jargon. A quick version may be fine for a landing page. It is dangerous for a payment system. Knowing the difference is part of the craft.

How to become a software engineer without a computer science degree: a 12-month plan

If I had to start again today, I would follow a plan like the one below. It is realistic for a graduate or a working professional who can give one to two hours a day, plus a longer block on weekends. It will not make you a senior engineer in a year, but it can make you employable or ready for your first paying clients.

Phase 1 (months 1 to 3): foundations

Learn HTML, CSS and basic JavaScript. Build three small things: a personal page, a simple business page and a form that works. Use free resources such as the documentation at MDN Web Docs, and practise on your laptop every day. Do not buy an expensive course yet. The goal in this phase is to prove to yourself that you can stick with it.

Phase 2 (months 4 to 6): data and back end

Learn a back-end language, PHP or Python or JavaScript on the server, and a database like MySQL. Build a small app that saves and reads real data, for example a customer list or a booking system. Add Git and put your code online. At this stage learn the basics of security: never trust user input, never store passwords in plain text, always use prepared queries.

Phase 3 (months 7 to 9): real work

Find one or two real people who need something small: a church, a tailor, a school, a small shop. Offer to build it at a fair price or even for a small fee, but with a written scope. Ship it, collect feedback and write down what you learned. This is your first portfolio project.

Phase 4 (months 10 to 12): specialise and sell

Pick a direction: business websites, WordPress, mobile apps, CRM, POS or automation. Learn one payment gateway such as Paystack or Flutterwave. Build a portfolio with three real projects and short case studies. Start telling people what you do. Your first paying clients will often come from people who already know you.

What it costs in naira

The cost of starting is smaller than most people think, but it is not zero. The table shows a rough first-year budget as at 2026. Prices change, so use it as a guide.

Many people ask me whether they need a paid bootcamp. My honest answer is that bootcamps help some people and not others. If you struggle to study alone, the structure and deadline can be worth the fee. If you are disciplined, free resources and a mentor can take you a long way. The most expensive mistake is not paying too much. It is paying for a course and then not building anything real.

Mistakes I made that you can skip

I do not enjoy remembering these, but they are the most useful part of my story.

1. Tutorial hell. I watched more than I built. The fix: after every hour of learning, spend an hour building something with it.
2. Learning too many tools at once. I chased every new framework. The fix: master one stack for a year before you add another.
3. Underpricing. I charged like a student long after I worked like a professional. The fix: price on the value you bring and the time you spend, not on fear.
4. No contracts. I trusted people’s word. The fix: a one-page scope and payment schedule for every job.
5. Ignoring security. My early forms could have been hacked by a beginner. The fix: learn the basics early, and treat customer data as a trust.
6. Working alone for too long. I avoided communities because I felt I was not good enough. The fix: join a local developers’ group, share your work and accept feedback.
7. Not writing things down. I forgot what I had learned. The fix: keep a simple notes file with problems and solutions. Future you will say thank you.
8. Burning out. I worked at night, then all day, for months. The fix: fixed routines and rest. I share how I manage this in how I stay productive as a founder.

Advice for career switchers: accountants, teachers, bankers and others

Many Nigerians reading this are not economics graduates. You may be an accountant in Lagos, a teacher in Kaduna, a pharmacist in Enugu or a banker in Port Harcourt. The idea that you must start again from zero is wrong. You are starting from a position of strength.

Use your old field as your first market

An accountant who learns to code understands bookkeeping problems better than most developers. A teacher who learns to code understands classrooms. A pharmacist who learns to code knows what an expiry date means. Build for the field you know, and you can compete with much more experienced developers, because you know the pain points. Your first clients are probably people in your old profession.

Be patient with speed, not with direction

You will feel slow next to people who studied computer science. That is normal. But do not drift. Pick a direction, for example “software for schools” or “systems for clinics”, and stick to it for a year. Depth in one area gives you a name faster than surface knowledge of ten.

Finding your first three clients

Do not begin with strangers on the internet. Begin with people who already know you. Write down twenty names of business owners, church leaders, school heads or shop owners you can speak to in person or on WhatsApp. Then ask each of them one question: “What is the most annoying repeated task in your business?” Listen, take notes and do not sell anything in that first chat. From twenty conversations, you will usually find three or four problems you can solve with software. Offer a small, clear fix at a fair price, with a written scope and a deposit. When the first client is happy, ask for a short review and an introduction to one more person. That is exactly how most of my early work grew. It is slow but it is solid, and every client becomes a reference you can point to.

Keep an income while you learn

Do not quit your job on day one. Learn in the evenings and weekends until you have at least a few paying projects and a few months of expenses saved. Economics taught me to respect risk. A slow, safe switch is better than a brave leap that ends in panic.

Why this matters in Nigeria

Nigeria has a young population, a weak job market for many graduates and a large number of small businesses that still run on paper and WhatsApp. That combination is a big opportunity for people who can build software. Starting costs are low compared with other careers. The demand is real. The risks are also real: some people sell false promises about “get rich with coding”, and many beginners quit when the first months feel hard. My advice is to treat it as a craft. It takes time, but time is what most of us have more of than money. And unlike many careers, you can prove your skill with real work, not just a certificate.

A note I give to every beginner. You do not need permission, a perfect laptop or a computer science degree. You need a small problem, a real person who has it, and the discipline to keep going when it is boring. My economics degree taught me to think. Building things for real people taught me to work. Together they made a career.

Key takeaways

• You can become a software engineer without a computer science degree. I did it from economics with a laptop, patience and real projects.
• Economics ideas such as opportunity cost, incentives and unit economics make you a better builder of business software.
• Learn in order: HTML and CSS, JavaScript, a back-end language and database, Git, APIs and security. Build something real at every stage.
• Get a paying client early, but always with a written scope and a deposit.
• Do not give away work, do not underprice for years and do not skip contracts.
• Use your old profession as your first market. Nobody knows your field’s problems better than you.
• Budget realistically: ₦400,000 to ₦1,500,000 in the first year, less if you already own a laptop.
• Protect your energy. Routines beat bursts of motivation.

Frequently asked questions

Next step: turn your idea into a working system

If you are a business owner reading my story, you probably do not want to become a developer. You want the result: a website, a system or an app that works. That is what I build every day. See my software developer services in Nigeria, browse my projects and read the lessons I wish I knew earlier. When you are ready, book a free consultation. And if you are the one learning to code, send me a message from the site and tell me where you are stuck. I answer as many as I can.