AnuraCode
I build and modernize software — web apps, mobile products, integrations, and content platforms.
AnuraCode
AnuraCode is how I work as an independent software engineer. I like learning every day and taking on projects that are actually hard.
My background is .NET and system integration, with later work on mobile products, progressive web apps, virtual reality, React/CMS sites, and high-traffic inventory systems.
English is my working language for international teams; Spanish is native. I am based in Colombia and collaborate remotely.
Mobility, then and now
When AnuraCode started, the industry was racing into phones and tablets: multi-touch, app stores, and a new kind of software people just called “apps”. Microsoft BizSpark helped ship the first product (ZoneTasks). That bet on mobility still holds — the devices and toolchains changed.
Today the same idea is broader: iOS, Android, the browser as a first-class platform (including Progressive Web Apps), and software that has to work on a phone in the field as well as on a desktop. AnuraCode still builds those experiences, plus the APIs, CMS, and integrations behind them.
What is an “App”?
“App” is short for application: a program people use on a phone, tablet, or computer. It is not just any program — it is shaped for how someone holds a device, taps, types, and comes back later. That still means iPhone and Android. It also means a fast website that behaves like an installed app, or a desktop client that talks to the same backend.
There are still two families, with a third in between:
Web apps (and PWAs)
A site that adapts to the screen and can, if you choose, be installed, work offline in parts, and send notifications. You need a network for many features, but you ship one codebase to every device that has a browser — no store review for every fix.
Native apps
Each platform (Apple, Google, and others) exposes APIs so the app looks and feels like it belongs there. Users install from a store. Publishers still follow rules on privacy, performance, and how revenue is shared. Store fees and cuts change over time; the constraint does not: you publish through their marketplace.
How can I build an “App”?
The paths from the early 2010s are the same three ideas, with newer names. I still help people choose among them instead of pretending there is one right stack.
Web first
A well-built website or PWA is often enough: marketing, catalogs, dashboards, content. Tools range from static sites to full product UIs. Faster to iterate, one URL, search engines can see it.
Native shell, web technologies
HTML, CSS, and JavaScript inside a native wrapper (today: Capacitor and similar; earlier: PhoneGap/Cordova). Part of the app can live on the device, so not every tap needs the network. Good when you already have a web product and need store presence or a few device APIs.
+ One codebase for several stores; web skills transfer.
− Not every OS feature; heavy UI can feel less native than Swift or Kotlin.
Cross-platform native frameworks
One project compiled toward each OS (Flutter, React Native, .NET MAUI — and earlier Xamarin, which we used on Parcero). You reuse business logic and still reach most platform APIs. Performance is close to fully native when the team is careful.
+ Shared logic; access to cameras, location, notifications; store-ready binaries.
− You still test on each platform; upgrades follow two OS calendars.
Platform SDKs
Swift/SwiftUI, Kotlin, or Windows/.NET when you need every API and the tightest UI. Maximum capability; more training and less reuse across phones. The right call for a single-platform product or a demanding module inside a larger app.