What I Learned as the First Engineer at a Fintech Startup

In April 2023, I joined CirclePe as the first engineer. Third person in the company, after the two founders. No codebase, no architecture, no team. Just a pitch deck and a banking partner willing to take a bet. Two and a half years later, I had built the entire fintech infrastructure — lending platform, credit decisioning engine, KYC/AML integrations, observability stack, API gateway — and scaled it to over 20 crore in lending volume. Then I moved on to Recur Club. This post is about what I learned during that time. Not the technical details, but the harder lessons about building from zero. --- ## 1. The First Architecture Decision Is the Most Expensive When you are employee number one, every technical decision you make becomes the foundation that everything else is built on. Choose a monolith or microservices? REST or GraphQL? PostgreSQL or MongoDB? Spring Boot or Node? There is no tech lead to consult. No existing codebase to follow. You are making irreversible decisions with incomplete information, and you have to make them fast because the founders are waiting for a demo. What I learned: optimize for speed of iteration in the first three months, then gradually optimize for correctness. Start with a well-structured monolith. You can always extract services later when you understand the domain boundaries. You cannot easily merge microservices that were split wrong. ## 2. Fintech Is Not Regular Software Building fintech infrastructure is different from building a SaaS product. The constraints are harder: - Every transaction must be auditable — you cannot just fix data in production and move on - Downtime means real money lost — a payment system that is down for 10 minutes might lose lakhs in transactions - Regulatory compliance is not optional — KYC, AML, RBI guidelines, data localization rules - Edge cases in financial systems can cause actual financial loss — an off-by-one error in interest calculation compounds into real money This forced me to think differently about engineering. I learned to write code that assumes everything will fail — idempotent operations, retry mechanisms, dead letter queues, comprehensive audit logs. Not because I was paranoid, but because in fintech, the cost of failure is not a 500 error page — it is someone not getting their money. ## 3. You Are Not Just an Engineer As the only engineer at a startup, your job is not to write code. Your job is to make the product exist. That means: - Talking to the banking partner to understand their API integration requirements - Sitting with the founders during investor meetings to answer technical questions - Writing API documentation because there is no technical writer - Setting up CI/CD because there is no DevOps person - Debugging production at midnight because there is no on-call rotation — you are the on-call rotation I learned more about product, business, and communication in those two and a half years than in all my previous experience combined. When there is nobody else to do it, you either figure it out or it does not get done. ## 4. Technical Debt Is a Feature, Not a Bug Every startup has technical debt. The question is not whether to accumulate it, but where to accumulate it strategically. I learned to distinguish between two kinds of debt: **Acceptable debt:** Quick implementations in non-critical paths that you will clean up when you have more context. An admin dashboard with hardcoded values. A reporting query that is slow but only runs once a day. **Dangerous debt:** Shortcuts in the critical path that compound. Skipping validation on financial transactions. Not implementing idempotency on payment callbacks. Using optimistic locking where pessimistic locking is needed. The skill is knowing which is which — and having the discipline to never take shortcuts in the dangerous category, even when the deadline is tomorrow. ## 5. Founding Engineer Is Not First Employee There is a meaningful difference between being a founding engineer and being the first employee. A first employee executes the CTO vision. A founding engineer defines the technical vision when there is no CTO. This means you carry a different kind of responsibility. If the architecture fails, there is no one else to blame. If the system scales, there is no one else who understands why. You are simultaneously the architect, the builder, the reviewer, and the person debugging production incidents at 2 AM. It is the most intense and educational experience I have had in my career. I would recommend it to any engineer who wants to accelerate their growth — but only if you are comfortable with the idea that on most days, you will not know what you are doing, and you will have to figure it out anyway. --- If you are considering joining a startup as the first engineer, my one piece of advice is: make sure you genuinely care about the problem being solved. The technical challenges are solvable. The motivation to push through the hard parts comes from caring about what you are building.