How to become a software developer in Kenya

Start with honest expectations

Software development is the practice of understanding a problem, designing a solution, writing code, testing it and maintaining it. Syntax is only one part. A useful learning plan must also include debugging, version control, documentation, security and communication.

Your first target is not “learn everything.” It is “build one small thing, explain how it works, and improve it after feedback.”

There are many valid entry routes: university or TVET study, structured training, self-directed learning, workplace exposure, or a combination. The right route depends on your access, learning style and the requirements of the roles you eventually pursue.

An eight-step developer path

1. Choose one field to test

   Compare frontend, backend, mobile and data work. Pick one for your next project; you can change direction with better evidence later.

2. Make your setup dependable

   Install the tools your path actually needs, learn where files are stored, enable account recovery, and keep a backup of work you cannot replace. When data access is limited, save official documentation for offline reading where its licence and format allow.

3. Learn transferable foundations

   Practise variables, decisions, loops, functions, data structures, input validation and error handling. For web work, add semantic HTML, CSS fundamentals and how the browser exchanges data with a server.

4. Use Git before the project feels important

   Create a repository, make focused commits, use branches for experiments and write a README. The official Git tutorial and GitHub Hello World guide cover the core workflow.

5. Build a small, locally meaningful project

   Start with data you create yourself: a market-price notebook, study planner, chama meeting record or small-stock tracker. Keep the first version narrow and use synthetic data instead of collecting people's personal details.

6. Test failure, not only success

   Try empty values, slow networks, incorrect formats, small screens and keyboard-only navigation. Record what failed and what you changed. A project that handles ordinary mistakes tells a stronger story than a large demo that only works on the happy path.

7. Publish the work and explain it

   Deploy only what is safe to make public. Your README should state the problem, users, main decisions, setup steps, limitations and next improvement. Include screenshots or a short demo when they add information.

8. Ask for specific feedback

   Instead of “Is this good?”, ask someone to complete one task, review one function, or challenge one design choice. Turn useful feedback into an issue, make the change, and document what you learned.

What credible proof of skill looks like

A portfolio does not need dozens of projects. Each selected project should make your contribution and reasoning easy to inspect.

• A working demo or clear local setup instructions.
• A readable repository history with no passwords, API keys or personal records.
• A README that names the problem, scope and known limitations.
• Tests or a documented manual test plan for important behaviour.
• Accessible labels, keyboard support and responsive layouts for user interfaces.
• Credit for tutorials, libraries, datasets and collaborators.

Use the beginner project guide if you need a scoped brief rather than another open-ended tutorial.

Kenya-specific checks before you publish

Approach opportunities with evidence

Read the actual requirements for each internship, attachment, junior role or freelance brief. Titles are inconsistent: two “frontend” roles can expect different tools and experience. Use the description to decide whether to apply and what evidence to lead with.

• Match your CV and portfolio links to the role's core work; do not claim tools you cannot discuss.
• Describe your own decisions and contribution, especially on group projects.
• Prepare to explain a bug, a trade-off and how you verified a change.
• Verify organisations and application links through their official websites before sharing personal documents.
• Check programme costs, contracts and refund terms directly with the provider. Inclusion in a community discussion is not an endorsement.

Primary resources to keep nearby

• MDN Learn Web Development — maintained learning material for web standards.
• Python's official tutorial — a primary reference for Python learners.
• Official Git documentation — concepts, reference material and tutorials.
• W3C introduction to web accessibility — why accessible products matter and where to begin.
• Office of the Data Protection Commissioner, Kenya — current official privacy guidance.

Frequently asked questions