From Finance to Full-Stack Developer: An Illustrative 10-Month Journey

1About This Story

Meet Vikram (illustrative). 29 years old, chartered accountant at a mid-size audit firm in Bangalore. Six years of financial modelling, client reporting, and Excel gymnastics.

Good salary, clear career path, and a growing certainty that he was spending his professional life doing things a computer could do better than he could — if only he could tell the computer what to do.

2The Starting Point: CA with a Spreadsheet Problem

The specific frustration: every quarter, Vikram and two colleagues spent three days manually consolidating expense reports from 40 freelancers across the firm's client engagements. The data was in different formats, different currencies, different levels of completeness. They'd been doing it the same way for six years.

"There must be a way to build something that handles this," he thought one evening, staring at the fifth pivot table of the day.

He didn't yet know how to build it. But the question — what would I need to know to solve this? — turned out to be a much more motivating starting point than "I want to learn to code."

3Month 1-3: The Frontend Foundation

Vikram started with freeCodeCamp's Responsive Web Design and JavaScript certifications — free, self-paced, browser-based. The HTML and CSS came quickly: structured, rule-based, similar to the logic of spreadsheet formatting. JavaScript was harder. The mental model of functions, variables, and event handlers was genuinely new.

His learning strategy: every concept he encountered, he immediately tried to connect to the expense report problem. When he learned about forms, he built a fake expense submission form. When he learned about arrays, he stored expense records in an array. The project was never far from his mind.

By the end of month 3, he had a crude static web page that let someone fill in an expense form and see the submitted entries in a table below. No backend. No database. But it was a real thing he had built, and he understood every line.

4Month 4: JavaScript Gets Real

Month 4 was React, and it nearly broke him. Components, props, state, hooks — the abstraction layer felt arbitrary. He spent two weeks on tutorials before a breakthrough moment: he rewrote his expense form as a React component.

Suddenly, the useState hook made sense because he could see what state was tracking. The list of expenses was state. The form inputs were state. Clicking "Submit" updated state, which re-rendered the list.

The conceptual shift: React isn't about HTML. It's about state and its visual representation. Once that clicked, component composition felt natural.

5Month 5: The Backend Revelation

The expense tracker needed to save data. Vikram discovered that his React app — running in the browser — couldn't directly connect to a database. He needed a server. He needed Node.js and Express.

The first working backend request felt like magic: his React form sent a POST request to a local Express server, the server received it, and logged the expense data to the console. The data had crossed a boundary — from browser to server. It was a three-line server and a two-line fetch call, but something had genuinely happened.

He spent month 5 on Node.js/Express basics, REST API design, connecting to PostgreSQL, and basic JWT authentication. The Full-Stack To-Do App guide on SkillVeris gave him the structural template he needed.

6Month 6-7: The Full-Stack Project

The expense tracker became his flagship project. Over months 6 and 7 he built it properly.

He gave the URL to five freelancer friends who'd complained about the same quarterly expense pain. Three of them used it for their next client invoicing cycle.

It worked. Real users, real feedback, real iteration.

• Frontend: React with Tailwind CSS. Multi-user login. Expense form with category, amount, currency, date, and freelancer name fields. A dashboard showing monthly summaries per freelancer.
• Backend: Node.js/Express REST API. JWT authentication. PostgreSQL database (hosted free on Supabase). Endpoints for creating, reading, updating, and deleting expense records.
• Deployment: Frontend on Vercel, backend on Railway. Public URL, live and working.

7Month 8: Building in Public

Vikram posted about the expense tracker on LinkedIn. "I spent six years reconciling expense reports manually. I spent two months learning web development to automate it. Here's what I built." Three screenshots, a live link, and a brief description of the tech stack.

The response surprised him. Fourteen people commented. A founder of a fintech startup messaged to ask if he'd considered adding multi-currency support (it was already on his roadmap). A senior developer from a Bangalore product company said it was the most practical portfolio project they'd seen in months.

He updated his LinkedIn headline to "Full-Stack Developer | React, Node.js, PostgreSQL | Ex-CA | Open to junior dev roles" and started the formal job search.

8Month 9: The Job Search Reality

Month 9 was intense and humbling. He applied to 50 positions. Most job descriptions asked for 2-3 years of experience he didn't have. He got 8 first-round interviews, 4 technical assessments, 2 second rounds.

He spent three weeks improving the expense tracker's mobile responsiveness and CSS polish based on the feedback.

• His React and Node.js skills were solid for his experience level — the project showed that.
• CSS and responsive design needed work — he'd been focused on functionality over polish.
• System design concepts (databases, API architecture) were stronger than most juniors because of the financial modelling background.
• Being a CA was a significant differentiator for fintech and financial product companies.

9Month 10: The Offer

Two offers came within a week of each other in month 10. Both were fintech companies. Both had seen the expense tracker. One interviewing manager had actually tried to sign up (the login worked; the free PostgreSQL tier had been sleeping, so it was slow on first load, but it worked).

He accepted a role as a junior frontend developer at a B2B expense management SaaS. The irony was not lost on him: the problem that started the entire journey — expense management — was now his job.

The salary was 10% higher than his CA role. The growth trajectory, he felt, was steeper.

10What Finance Skills Transferred

Several habits from his finance career mapped directly onto software development.

• Structured problem decomposition: breaking a complex financial model into cells, formulas, and dependencies is identical to breaking a software feature into components, functions, and data flows.
• Attention to edge cases: audit work builds the habit of asking "what happens when the input is wrong?" — exactly the mindset for defensive programming and testing.
• Stakeholder communication: explaining a cash flow projection to a non-financial client is the same skill as explaining a technical decision to a non-technical product manager.
• Domain knowledge: for fintech roles, a developer who understands financial concepts from the inside is significantly more valuable than one who has to learn them from scratch.

11What He Would Do Differently

Looking back, four changes would have made the journey smoother and faster.

• Start CSS fundamentals earlier: he deprioritised visual polish and paid for it in interviews. A good-looking app signals professional standards beyond just working code.
• Write tests from the start: he added no automated tests to his project. Several technical interviews asked about testing approach; he had no good answer.
• Network at local tech meetups sooner: the LinkedIn post worked, but in-person introductions in months 7-8 would have accelerated the job search significantly.
• Target fintech roles from month 6: the domain overlap was obvious in retrospect; he wasted applications on generic software roles where the CA background was irrelevant.

12Key Takeaways

The story distils into a handful of repeatable principles for any career switcher.

• The most powerful portfolio project solves a problem you personally experienced. Genuine domain expertise shows.
• Finance, law, medicine, and other professional backgrounds are assets for developers in those domains, not liabilities.
• Build in public from month 7 or 8 — even one LinkedIn post about a real project can open doors that cold applications don't.
• Apply before you feel "ready." Month 9 interviews revealed specific gaps faster than any curriculum.

13Start the Same Path

You can follow Vikram's learning path with three focused resources.

• JavaScript ES6+ Features — the foundation before React.
• React Hooks Explained — master the core React concepts.
• Full-Stack To-Do App Project — the structural template for your own project.

14Frequently Asked Questions

Is a CA or finance background helpful for becoming a developer? Especially for fintech, banking, and financial software roles, yes — significantly. Domain knowledge (accounting principles, financial reporting, tax logic) is hard to learn on the job and highly valued by companies building in that space. For roles outside finance, the analytical and communication skills still transfer; the domain knowledge just applies less directly.

Is 10 months realistic without a bootcamp? For a junior frontend or full-stack role: yes, for someone who can dedicate 2-3 hours daily and builds real projects throughout. Bootcamps can compress this to 3-6 months for full-time students, but at significant cost. The self-taught path in this story cost nothing beyond time, and the domain expertise from the prior career added value the bootcamp route doesn't generate.

What would a good expense tracker project look like on a CV? "Built a full-stack expense management application (React, Node.js, PostgreSQL) used by 5 freelance clients to track and categorise quarterly expenses across multiple currencies. Deployed on Vercel and Railway with JWT authentication." Note the concrete details: users, purpose, tech stack, deployment. Not just "expense tracker app."

How important is having real users for a portfolio project? Significantly. Even 3-5 real users (friends, colleagues, Reddit strangers) changes the story from "I built a demo" to "I built something people use." Employers evaluate judgment, not just technical skill. Choosing a problem worth solving and finding people who'd actually use the solution demonstrates product thinking that tutorials can't teach.