Carlos Alberto Ortiz Ortiz

Context

Elektra Go is a fintech app for cross-border remittances: sending money from the US to Mexico, plus buying airtime, paying services, applying for a card, moving funds over ACH, and topping up the balance from stores in the US. The product is built for Mexican users living and working in the United States, which means every flow has to be simple enough to use after a long shift and trustworthy enough to move someone’s paycheck.

The codebase was the real constraint. It had passed through several external consultancies, it was in-house development with no documentation, and it carried years of dead code, duplicated logic, and dependencies nobody could justify anymore. Shared flows ran across the entire app, so almost nothing was truly isolated — change one thing and you could break a payment path you had never opened.

The team was large and distributed: 8 Android engineers (4 senior, 4 mid-level), 8 on iOS, around 8 on backend, about 5 in QA, plus tech leads and several product owners. I joined as an independent contractor through a US staffing agency, and later moved to a direct contract with the client’s internal contracting entity — retained on delivery quality rather than on the agency relationship.

What I did

As one of four senior Android engineers, I did code reviews, made architecture decisions, and mentored the mid-level engineers through pairing sessions.

Stabilize before migrating. The first phase was subtraction: cleaning up dependencies, deleting code that was no longer used, and starting to centralize logic that had been copy-pasted across dozens of screens. Migrating a feature on top of a codebase you do not understand just moves the mess to a new syntax.

Migrate the UI. Once the ground was stable, we moved screens to Jetpack Compose. We started with classic Navigation and eventually migrated to Navigation Compose. For the Compose work itself I used AI-assisted tooling to accelerate UI prototyping and cut boilerplate.

Rebuild the core. The remittance and transaction flow was officially untouchable — it was the product. Eventually it had to be rebuilt anyway, with proper architecture and practices. Getting there took sustained pressure from the senior engineers, because the honest cost was the time required to understand the basecode before touching it. Without documentation, and with shared flows crossing the whole app, reading and tracing dependencies was the work.

Fix production. Details in the section below — the app lost access to some Google services after a signing hash changed.

Architecture and decisions

Hilt over Koin. We chose Hilt because it is the Android standard and the team already knew it. Koin was technically viable and would have been faster to adopt in places, but adding a third-party dependency meant going through approval with the product owners. The standard option was the one we could justify without a fight, and consistency across 8 Android engineers mattered more than a small ergonomic win.

Order of migration by risk, not by visibility. The first screens to move to Compose were the low-impact “side features” — the ones with the fewest dependencies on the rest of the app. That gave us real migration experience on code that could not take down a payment, and it built the pattern before we applied it to anything critical.

Everything is a shared flow until proven otherwise. The founding assumption became: this flow is referenced somewhere you have not looked. It changed how we planned every refactor and why dependency cleanup had to come before feature migration.

The signing hash incident

A change in how CI/CD generated the build changed the hash the app was signed with. The app kept working for most users, but integrations with some Google services broke because the registered certificate hash no longer matched.

Diagnosing it meant working backwards from the symptom: the build was green, the APK installed, but the service handshake failed. I traced it to the signing configuration change, then had to recover the correct hash — which no longer matched anything we had on file.

The fix required generating a temporary production build purely to extract the new hash from it, updating the value in the Google developer console, and verifying the affected integrations. The lesson was that signing identity is production configuration, not build detail, and it deserves the same change control as a database migration.

Impact

• App load time reduced by 1–1.5 seconds.
• 70% of the legacy UI running on Jetpack Compose.
• Transaction core rebuilt on a maintainable architecture, with the senior team aligned on why it was worth the cost.
• Release cadence of 2 per month held while the migration was in flight.
• A production incident resolved without a user-facing outage.

What I would do differently

I would use AI to map the basecode from day one. Understanding an undocumented codebase is exactly the kind of reading-heavy, high-volume work that agents are good at, and it is the best use of AI I have found when starting on an existing project: feed it the unfamiliar modules, ask it to trace shared flows and dependencies, and get a map in hours instead of days. We lost real time doing that manually, and it would have shortened the path to the core rebuild.

Context

Femsa was opening a new business line and needed to start accepting card payments. The app was the pilot: an Android and iOS application for charging debit and credit cards, connected to a physical mPOS device. From the app you paired with the mPOS, ran the entire charge flow, and generated the receipt as a PDF ticket.

That made the hardware the hardest part of the product. The mPOS is not a peripheral you can treat casually — it is a certified payment device with its own protocol, its own permission requirements on each platform, and manufacturer instructions that have to be followed exactly. The devices also carried keys that required custom firmware updates, which meant device provisioning was part of the work, not a setup step someone else handled.

We were a Palo IT team assigned to Femsa: 4 Android and 4 iOS engineers, with the same team covering backend.

What I did

I worked on the Android application and led the shared core in Kotlin Multiplatform. The app itself followed the standard modern Android setup — Jetpack Compose, Navigation, StateFlow — with GraphQL for data.

The KMP core owned the parts of the system that must behave identically on both platforms:

• Networking and request building
• Request validations
• Transaction rules
• Device state

Architecture and decisions

What we shared, and what we refused to share. UI and permissions stayed native on each platform. This was deliberate: permissions and UI are where the platforms genuinely differ, and forcing them into a shared layer would have traded a real abstraction problem for a fake one. The rule was that only logic which must agree across platforms belongs in the core — everything else stays where it can use the platform properly.

iOS consumed the module through CocoaPods. The iOS team implemented the integration and consumed the shared code as a dependency in their app, which kept ownership on their side without forking the logic.

GraphQL was inherited, not chosen. Femsa already had a GraphQL-based prototype, so keeping it was a constraint rather than a decision. Working inside an existing protocol choice is a normal part of contract work; the job is to make it predictable, not to relitigate it.

The ~40% figure, honestly

The 40% is an estimate, not an instrumented measurement. It comes from the number of sprints we did not need after deciding to use KMP, compared against the original estimate for building the same capability natively on each platform.

The business case was straightforward: two cores means two implementations to maintain, more engineers across two teams, and a guaranteed drift between them as each platform evolves on its own schedule. One core removes the drift entirely and the second platform becomes a consumer instead of a parallel project.

Testing the shared layer

The most valuable tests were the ones that pinned cross-platform behavior. A large part of the request body was constructed inside the shared module, so the key assertion was that both platforms produce an identical request for the same transaction. If Android and iOS generate the same payload from the same inputs, the shared layer is doing its job.

What I would do differently

Understand the scope of KMP earlier and more precisely. It is easy to see the “shared code” win and start moving things into the module that should have stayed native. Drawing that boundary properly — logic yes, UI and permissions no — is the decision that determines whether a multiplatform core stays maintainable or becomes a second framework nobody wants to touch.

Impact

• Around 40% less development time on shared logic versus two native implementations.
• One core consumed by Android and iOS instead of two parallel codebases.
• Card payment acceptance shipped end-to-end: connection, transaction, and PDF ticket.
• A reusable integration pattern for future platforms.

Context

Covalto is a Mexican fintech that issued loans and credits to entrepreneurs across sectors like agriculture. The app I worked on was the front door of that business: the place where a credit application happened. Applicants signed documents digitally and attached whatever the application required — the paperwork that used to be a trip to an office.

The team was around 15 people across Android, iOS, QA, and product, distributed across Mexico, Colombia, Switzerland, and Turkey. Remote-first Scrum, working across time zones.

What I did

I delivered features on the application flow with MVVM and Uniflow, the MVI implementation the project already used. The piece I owned most directly was the documentation attachment flow: uploading PDF and PNG files with a size limit, which sounds trivial and is not. File handling in a financial application means validation, failure states, and making sure a user who uploaded the wrong document is not stuck.

Alongside feature work I wrote unit tests with JUnit, MockK, and Robolectric, and validated REST integrations with Insomnia and Postman before handing them to QA.

A note on the architecture

Uniflow was already in the codebase when I joined; the reasoning behind adopting it predated me, and I worked within the pattern rather than relitigating it. What I can speak to honestly is what it bought us in practice: a single ordered state per screen, which matters in a multi-step application where a wrong intermediate state is a real defect rather than a visual glitch.

Why it ended

The company was acquired by another bank and went through a full restructuring, which ended the engagement. Short contract work has that in it — the engineering outlives the org chart, and the features shipped are still in the product.

Impact

• Credit application features delivered on a two-week Scrum cadence in a distributed team.
• A documentation attachment flow with explicit file-type and size validation.
• REST integrations verified before QA, reducing regression churn.

Context

After three years building internal banking applications at Invex, I moved into a lead role. The trigger was the state of the codebase I already knew well: the delivery app I had built was still on MVP, and years of accumulated practice had turned it into code that was increasingly expensive to maintain. It needed more than a refactor.

What I did

I proposed the rewrite and took the initiative to do it in parallel with the production version rather than declaring a freeze on the existing app. That was the decision that made the project survivable: the business kept receiving fixes and small changes on the old app while the new one was built next to it.

Moving into the lead role changed what my work actually was:

• Architecture decisions were mine now, not something I implemented from someone else’s design.
• Planning — breaking the rewrite into timeboxes and deliverables tied to each release, so progress was visible instead of a long silent march.
• Mentoring and delegation — new engineers joining the team needed the patterns explained and the work distributed, which is the part of senior work that does not appear on a commit log.

We settled on Kotlin, MVVM, and Jetpack components (Room, Navigation, LiveData) as the standard, and standardised code reviews so the new project would not drift back toward what it replaced.

Architecture and decisions

Rewrite, not migration. The MVP codebase was not migratable in practice — poor practices and spaghetti logic meant a mechanical port would have carried the same problems into new syntax. Rewriting from zero was more expensive upfront and cheaper over the following years.

Parallel delivery. The alternative was a freeze on the production app, which would have meant pausing the business to improve it. Running both tracks simultaneously was more work for the team but kept the product alive, and it gave us a real benchmark: the new code had to be demonstrably easier to change than what it replaced.

Adoption was not the hard part. Standardising on Kotlin and MVVM met little resistance, because the alternative was maintaining the app we were all already tired of. When the status quo is painful enough, the standard argues for itself.

Impact

• Internal app rebuilt from zero on Kotlin, MVVM, Room, Navigation, and LiveData.
• Production app continued to receive changes throughout the rewrite.
• 3–5 engineers mentored and given ownership of defined pieces of the work.
• Code review standards that outlasted the project.

Context

Invex is a Mexican bank. The problem the app solved was physical: to receive a credit card, the customer had to go to a branch and do the paperwork in person. The app changed that flow entirely — a courier arrives wherever the customer is, delivers the card, and collects the documents needed to activate it on the spot. More than 100 operators used it across the country.

That last part is what made the app interesting. It was not a form with a database behind it; it was a banking instrument running in the field, on devices and networks you do not control, in the hands of people who are not technical, standing in front of a customer.

What I did

I built the delivery application, including the biometric authentication module that verified the card was being handed to the person they claimed to be. That check is the whole point of the flow in a fraud sense: without it, “delivered to the right person” is just an assertion by whoever is holding the phone.

I worked in Java and MVP initially, with SQLite and Shared Preferences for persistence, and Material Design for the interface. Over the following years that foundation became the thing we replaced — I go into that in the lead role.

Architecture and decisions

The security decision that mattered most was making biometrics a required step rather than an optional convenience. It is easy to add fingerprint as a login shortcut and call it security. Here it was identity evidence for a specific handover, and the flow had to be built so that skipping it was not possible.

The other lesson was about the environment. Software that runs in the field has to assume bad connectivity, old devices, and interrupted flows. Persistence that survives an app being killed mid-delivery is not a nice-to-have; if the record disappears, the physical card is already gone.

Impact

• 100+ operators running the delivery flow nationwide.
• Customer no longer needs a branch visit to receive and activate a card.
• Biometric verification reduced identity-fraud exposure at handover.
• A three-year base of domain knowledge that directly informed the later rewrite.

Context

iGenter is a staffing agency, and this is where my professional mobile career started. Agency work means building for two audiences at once: the company’s own operations, and the people the company places.

What I built

An internal app for agency employees. It handled check-in and check-out when employees arrived at or left their work area, vacation requests, shift schedules, and payslips. This is back-office software in the best sense — it replaced paperwork and a phone call for the people who needed an answer about their own schedule.

A job board, in Android and iOS. Candidates registered, browsed the positions the agency had open, and applied from the app. Two platforms, one product, which is where I learned what actually differs between them — and how much of the difference is platform convention rather than real constraint.

What I did

I developed across both platforms and owned the full lifecycle: build, Play Store submission, and the production incidents that followed. I integrated Google Maps API and GPS services, REST APIs with Volley, SQLite persistence, token-based session management, and Facebook SDK for social login.

What I took from it

Shipping through a store teaches things development never does. Device fragmentation, review processes, and crash reports from phones you have never seen are the real conditions, and they push you toward defensive networking and explicit session handling.

Session management in particular is where I learned to reason about auth state properly — expiry, refresh, and what the user sees when their session dies mid-application.

Impact

• Two shipped products: an internal employee app and a two-platform job board.
• Full release ownership on Android and iOS.
• Production incidents diagnosed across a wide range of devices and OS versions.

Context

Before I moved fully into software engineering, I worked in digital marketing and web operations at Pirelli. It is not Android work, but it is where I learned how a business actually consumes the software it asks for.

What I did

I supported the implementation of a B2B platform inside the digital marketing area, coordinated digital campaigns and email execution, and handled communication with external vendors. I also built internal registration and notification workflows using Google Apps tooling — small automation that replaced manual coordination.

Why it matters

Working on the business side first changed how I build software. I have seen what happens when a platform is delivered without understanding the people who operate it, and I have been the person doing the manual work a system was supposed to remove.

That perspective shows up in how I write features: I care about the operator, not just the user in the design mock. It is also why I gravitate toward automation — removing manual work is the part of software I find genuinely satisfying.

Impact

• B2B platform implementation supported end-to-end.
• Internal workflows automated with lightweight Google Apps tooling.
• A business-side perspective that shaped my later engineering decisions.

Context

This is the earliest stage of my career: a digital agency where I worked across web implementation and marketing for a range of clients, before specializing in mobile.

What I did

I worked across SEO, PPC, and SEM, planned campaigns, and built and maintained websites on WordPress and Magento. I was also the direct point of contact with clients, which meant translating a vague business goal into something that could actually be built.

Why it matters

Two things from this period stuck with me.

The first is CMS and theme work, which is where I learned to read someone else’s markup and CSS and change it without breaking it — the same skill that later became legacy Android migration.

The second is client communication. Explaining trade-offs to a non-technical stakeholder, in writing, without over-promising, is a skill that most engineers are never taught. I learned it early and I still use it in every contract engagement.

Impact

• Delivered CMS-based web implementations with direct client ownership.
• Built early expertise in search and paid acquisition.
• Learned to translate business requirements into shipped work.