The same team owns the build and the spend
When a campaign underperforms, the fix is often an onboarding step or a mis-fired event rather than a bid adjustment. We can make that change, because we wrote the code and we run the account.
Product engineering · Digital advertising · Growth
We build products. Advertise them. And optimise them for growth.
MNF Infotech is a product engineering business and a digital advertising agency in one. We build the mobile applications and web platforms, plan and manage the campaigns that bring people to them, and hold both to the same set of numbers.
- L1Product surfaceAndroid · iOS · Web
- L2APIs & servicesREST · Auth · Webhooks
- L3Cloud runtimeFunctions · Storage · Jobs
- L4Event & revenue signalGA4 · Firebase · BigQuery
- L5AcquisitionSearch · PMax · App campaigns
Return path What acquisition learns is fed back into the product, not filed in a monthly report.
- 01Mobile & web engineering
- 02Google, Meta & app advertising
- 03Tracking, analytics & attribution
- 04Optimisation & scaling
What MNF Infotech is
Two businesses, run as one system.
MNF Infotech is a technology and product engineering provider and a digital advertising agency. We build the applications and platforms, and we plan, buy and manage the advertising that puts them in front of people.
Those are normally two suppliers with two contracts and one gap between them. Holding both means a disappointing return can be traced to an onboarding step, a mis-fired conversion or a bidding decision — and then fixed wherever it actually lives.
01BUILD
Product engineering & technology
Native mobile applications, web platforms, the backend services and cloud infrastructure underneath them, and the automation that removes repetitive work around them.
- Mobile apps
- Web platforms
- Backend
- APIs
- Cloud
- AI & automation
- UI/UX
02ADVERTISE
Digital advertising agency
A working advertising practice for businesses promoting apps, websites, products and services: strategy, media planning, campaign management, creative direction and reporting.
- Google Ads
- Meta Ads
- App advertising
- Search
- Display
- YouTube
- Media management
- Creative strategy
- Campaign management
03GROW
Performance & analytics
The measurement that makes the first two accountable to each other, and the ongoing optimisation of product, pipeline and spend as one system rather than three.
- Conversion tracking
- GA4 & Firebase
- Attribution
- Revenue measurement
- User acquisition
- Campaign optimisation
- Product optimisation
- Scaling
The integrated model
Seven stages, three territories, one loop.
Each territory hands to the next, and the last hands back to the first. Bought separately, the hand-offs are where accountability disappears.
01 / BUILDProduct engineering
- 01BuildShip the productApps · platforms · APIs · cloud
- 02MeasureInstrument it as it is writtenEvents · conversions · values
02 / ADVERTISEDigital advertising
- 03AdvertisePlan strategy, creative and mediaSearch · social · video · app
- 04AcquireBuy against real signalsCampaigns · budgets · bidding
03 / GROWData & growth
- 05AnalyseRead what actually happenedCohorts · funnels · attribution
- 06OptimiseChange the thing that is wrongProduct · pipeline · campaign
- 07ScaleIncrease only what holdsBudget · geographies · capacity
07 → 01 The loop closes. What optimisation learns is written back into the product and the campaign, so the next cycle starts with better information than the last — which is only possible when the same business owns all three territories.
Why it matters
The seams are where the money goes.
Engineering, advertising and measurement are usually bought from three different suppliers. Every one of them can do their part correctly and the result can still lose money, because nobody is accountable for the joins between them.
We are set up to remove those joins. The same business writes the application, defines the events that describe it, and spends against the signals those events produce — so there is one place to ask why a number moved.
Bought in pieces
- The app ships before anyone has agreed what an activation actually is.
- Conversion events get bolted on afterwards, by whoever has capacity — usually neither the agency nor the developer.
- Campaigns optimise toward installs, because installs are the only thing being counted.
- Nobody owns the gap between what the product does and what the ad account can see.
Run as one system
- The event model is written alongside the feature, not reconstructed after launch.
- Conversions carry value, so platforms learn from revenue instead of volume.
- The same team can change the app, the API and the campaign in the same week.
- Every performance claim traces back to a number inside your own data.
Capabilities
Thirteen capabilities across three business lines.
Build it, advertise it, measure and improve it. Each band feeds the next, and any capability can also be engaged on its own when that is what a project actually needs.
01
BUILDProduct engineering & technology
The applications, interfaces, services and infrastructure your business actually runs on — mobile, web, backend, cloud and the automation around them, built by the same people who will later measure and advertise them.
02
ADVERTISEDigital advertising & media
A working advertising practice: strategy, media planning, campaign management, creative testing and reporting across search, social, video and app platforms — run against your own conversion data rather than platform defaults.
03
GROWData, measurement & growth
The layer that keeps the other two honest. Event models, conversion tracking and attribution that make performance legible, and continuous optimisation of the product and the spend together rather than one at a time.
Not sure which of these your problem falls under? Describe the outcome you need and we will tell you what it takes — including when the answer is less work than you expected.
Compare all servicesProduct lifecycle
Ten stages, one continuous line.
A product does not stop at launch, and growth does not begin there. These are the stages we work through — and the point at which each one starts paying for itself.
01Definition
Find the constraint that actually matters
We start by separating the problem you described from the problem the numbers describe. That means reading whatever already exists — an app, an ad account, a spreadsheet, a support inbox — and identifying the single constraint that is holding the outcome back. Most projects arrive with a proposed solution attached; this stage exists to test whether it is the right one.
What comes out of it
- A written statement of the constraint and how we would know it had moved
- An audit of what already exists: product, data, accounts, infrastructure
- An honest view of what is not worth building yet
- 01Definition
Discover — Find the constraint that actually matters
We start by separating the problem you described from the problem the numbers describe. That means reading whatever already exists — an app, an ad account, a spreadsheet, a support inbox — and identifying the single constraint that is holding the outcome back. Most projects arrive with a proposed solution attached; this stage exists to test whether it is the right one.
- A written statement of the constraint and how we would know it had moved
- An audit of what already exists: product, data, accounts, infrastructure
- An honest view of what is not worth building yet
- 02Definition
Define — Scope, success criteria and the event model, before code
Scope is written down with the measurement attached. If a feature is meant to increase activation, we define what an activation is, where the event fires and what value it carries — at the same time we agree the feature exists. This is the stage that makes everything after stage 07 possible, and it is the stage most often skipped.
- Functional scope with explicit inclusions and exclusions
- An event and conversion model with names, parameters and value definitions
- Acceptance criteria written in terms someone outside the project can check
- 03Definition
Design — Interface decisions made against real tasks
Interface and flow are designed around the tasks users need to complete, on the devices they will use, in the states the system will actually be in — empty, loading, failed, offline. We design the unhappy paths as deliberately as the happy one, because those are where retention is won or lost.
- Screen and flow designs covering primary, empty, loading and error states
- A component and type scale carried through to implementation
- Accessibility decisions — contrast, target size, focus order — made up front
- 04Delivery
Engineer — Build it so the second year is cheaper than the first
Application code, services and integrations are written to an architecture that can be reviewed and reasoned about — clear module boundaries, typed contracts between layers, and no clever indirection that only the original author can follow. We optimise for the team that maintains this after launch, which is often your team.
- Application and service code in your repository, with history
- Typed API contracts and documented integration points
- Environment configuration separated from code, secrets outside the repo
- 05Delivery
Instrument — Wire the measurement in as the features land
Events, conversions and revenue signals are implemented alongside the features that emit them, then verified in a debug environment before release. Instrumentation added after launch always describes a product that has already changed; instrumentation added with the feature describes the product you shipped.
- Analytics and conversion events implemented and verified against the model
- Attribution and platform links configured and tested end to end
- A written map of every event, where it fires and what it is used for
- 06Delivery
Launch — Release with a way back and a way to see
Store submission or production deployment, with monitoring, error reporting and a rollback path in place before the release goes out rather than after the first incident. For app releases this includes store listing readiness, policy-sensitive review points and staged rollout where the platform supports it.
- Production deployment or store submission, with build and signing set up
- Crash, error and uptime monitoring reporting to a place someone reads
- A rollback or staged-rollout plan agreed before release
- 07Growth
Acquire — Spend against signals the product actually emits
Campaigns are structured around the conversion and value signals built in stage 05, not around whatever the platform offers by default. Account structure, geography, creative sets and bidding are chosen to give the system enough clean signal to learn from, and to keep tests separable once spend increases.
- Campaign architecture mapped to product events and value, not just installs
- Creative and audience test plan with a defined read-out point
- Budget and bidding approach documented, with the assumptions stated
- 08Growth
Analyse — Read cohorts, funnels and attribution together
Platform reporting, product analytics and revenue data are read side by side, because each one is wrong on its own. We look at what a cohort did after the install, not only what it cost to get, and we say plainly when the data is too thin to support a conclusion.
- Reporting that connects spend to in-product behaviour and revenue
- Cohort and funnel views that survive being questioned
- A short written read: what moved, what did not, and what is still unknown
- 09Growth
Optimise — Change the thing the evidence points at
The fix for a bad ROAS is not always in the ad account. Sometimes it is an onboarding step, a payment failure, a slow API call or a mis-fired event. Because the same team owns the product, the pipeline and the campaign, the change is made where it will work rather than where the contract happens to allow.
- A prioritised list of changes across product, data and campaign
- Implemented changes with the before-and-after measurement attached
- Retired tests and abandoned ideas recorded, so they are not repeated
- 10Growth
Scale — Increase only what holds under load
Scaling is where unnoticed weaknesses become expensive: an API that was fine at a thousand users, a cost model that only worked at low volume, a campaign that only performed in one geography. We raise budget, infrastructure and scope in steps, and check that each step still holds before taking the next.
- Infrastructure and cost review against real usage, not projected usage
- Staged budget and geography expansion with defined stop conditions
- An ongoing support and iteration cadence agreed in writing
Not every engagement runs all ten stages. A campaign-only engagement starts at 07; a product taken over mid-flight usually starts at 05. The sequence describes the full arc, not a compulsory package.
Engineering
Two surfaces, one engineering standard.
Almost every product reaches its users through a phone or a browser. The decisions differ; the discipline behind them does not.
01 / Mobile product engineering
Applications that survive their own success.
- Native where it counts
- Kotlin and Jetpack Compose on Android, Swift and SwiftUI on iOS. Native when the product depends on device capability, background work or store-level integration — and we say so when it does not.
- Built for the second year
- Clear module boundaries, typed contracts, dependency injection that a new developer can follow. The architecture is chosen so the maintenance cost does not exceed the build cost.
- Store review as an engineering task
- Permissions justified, data safety and privacy declarations prepared against what the code actually does, staged rollout configured before submission rather than after a rejection.
- Kotlin
- Jetpack Compose
- Swift
- SwiftUI
- Firebase
- Push & deep links
- In-app purchase
- Crashlytics
02 / Web platforms
From marketing site to production web application.
- Rendering decided per surface
- Static where content is stable, server-rendered where it is personal, client-side only where interaction demands it. The decision is made per route, not once for the whole application.
- Performance as a requirement
- Largest Contentful Paint, layout stability and interaction latency are treated as acceptance criteria, not a post-launch clean-up. Third-party scripts get a budget like everything else.
- Search architecture, not sprinkled keywords
- Semantic structure, one accurate heading hierarchy per page, canonical URLs, sitemaps and structured data that describes what is genuinely on the page.
- Next.js
- React
- TypeScript
- Node.js
- Tailwind
- Core Web Vitals
- Structured data
- Design systems
The same commit that ships a feature ships the event that describes it. This is the join between engineering and growth, and it is where most projects lose it.
Infrastructure & measurement
The parts nobody sees, that everything else depends on.
Services, environments and the measurement layer decide whether a product is cheap to run and honest to report on — or whether every question about performance turns into an argument about the data.
A
Clients
- Mobile applicationAndroid · iOS
- Web applicationNext.js · React
- Internal toolsOps · Support
B
Services
- API surfaceREST · versioned
- Identity & accessAuth · roles · tokens
- Domain logicOne place, not three
- Background workQueues · schedules
C
Data & runtime
- Primary databaseModelled, migrated
- Cache & sessionsRead paths
- Object storageMedia · exports
- Event streamProduct telemetry
D
Measurement bus
every rail above reports into this- WarehouseBigQuery
- ReportingCohorts · funnels
- Conversion signalsGA4 · Firebase · Ads
- OptimisationProduct · pipeline · spend
B · Backend & APIs
One place where the business rules live, a versioned contract in front of them, and error behaviour that a client application can actually handle.
C · Cloud engineering
Environments sized to the workload, deployment that can be rolled back, backups that have been restored at least once, and a cost line someone reviews.
D · Data & analytics
An event model written with the product, verified before release, exported to a warehouse, and read as cohorts rather than as a single monthly number.
Advertising & growth
Growth starts inside the product.
Campaign performance is mostly decided before a campaign exists. What a bidding system can learn is limited by what your product reports, and what your product reports is an engineering decision, not a media one.
It is why our advertising practice is not a separate service bolted onto a build. The people who define the conversion event are the people spending against it, which removes the most common excuse in this industry.
Acquisition circuitClosed loop · not a funnel
- 01AcquisitionSpend reaches a personSearch · PMax · App campaigns
- 02First sessionThey arriveStore listing · landing page · onboarding
- 03Product behaviourThey do somethingActivation · feature use · return visit
- 04ConversionSomething of value happensPurchase · subscription · qualified lead
- 05RevenueValue is recordedAmount · currency · refund state
- 06AnalyticsIt becomes readableCohorts · funnels · attribution
- 07OptimisationSomething changesProduct · event model · campaign
Stage 07 rewrites stage 01. Each cycle starts with better information than the last — provided stages 03 to 05 were built to produce it. That is the part campaigns cannot buy from outside the product.
What high-quality acquisition actually depends on
None of these are campaign settings. All of them are decided in the product and the pipeline.
- 01Events that describe reality
- If an event fires on a screen view rather than on the action that matters, every number downstream is measuring the wrong thing — accurately.
- 02Value on the conversion
- A conversion without an amount tells a bidding system that every customer is worth the same. Sending real value is what lets it stop buying the cheap ones.
- 03A product worth arriving at
- Acquisition can only deliver people to the first session. Whether they stay is decided by onboarding, speed and whether the thing works — all engineering problems.
- 04Reconciliation you can defend
- Platform reporting and your own data will disagree. The job is to know why, and to be able to say which number a decision was made on.
AI & automation
One capability, not the whole pitch.
We are not an AI company. We use language models where they remove a repetitive job better than code alone would, and we use ordinary software everywhere else.
MNF Infotech does not train or own foundation models. We integrate third-party model APIs, and we tell you which provider processes what, before anything is built on it.
- 01Document and data extraction
- Invoices, statements, forms and messy exports turned into structured records, with a confidence threshold and a review queue for anything the model is unsure about.
- 02Classification and routing
- Enquiries, tickets and transactions sorted and sent to the right place, using rules where rules are reliable and a model only where they are not.
- 03Reporting that writes itself
- Recurring reports assembled from your own data on a schedule, with the numbers coming from the warehouse and the commentary generated around them.
- 04Internal tools with a model inside
- Small, single-purpose interfaces for your team — search across internal documents, draft responses, summarise a case file — with access control and an audit trail.
Technology
The tools we actually work in.
Chosen because the work needs them, not because they look current on a capability slide. Where a boring choice is the right one, we make the boring choice.
01
Mobile
- Kotlin
- Jetpack Compose
- Java
- Android SDK
- Swift
- SwiftUI
- Xcode
- Gradle
02
Web
- TypeScript
- React
- Next.js
- Node.js
- Tailwind CSS
- HTML & CSS
- Web Vitals
- Playwright
03
Backend & data
- REST APIs
- PostgreSQL
- MySQL
- Redis
- SQL
- Webhooks
- Cloud Functions
- Cron & queues
04
Cloud & delivery
- Google Cloud
- Firebase
- AWS
- Vercel
- Docker
- GitHub Actions
- CI/CD
- CDN & caching
05
Measurement & growth
- GA4
- Firebase Analytics
- BigQuery
- Google Tag Manager
- Google Ads
- Looker Studio
- Crashlytics
- Attribution
Product and platform names above are third-party trademarks used descriptively to state what we build with. Their appearance here does not indicate partnership, certification, sponsorship or endorsement by their owners.
Why MNF Infotech
Six reasons that are not ‘quality, innovation, support’.
Every technology supplier claims those. These are the specific operating decisions that make a difference to what you get, and what it costs you later.
Measurement is designed before it is needed
The event and conversion model is written at scoping, alongside the feature list. Nothing is reconstructed after launch from whatever happened to be logged.
You own the accounts, the code and the data
Repositories, cloud projects, analytics properties and advertising accounts are set up in your name wherever you want them there. Our access is scoped, documented, and removed when the engagement ends.
Architecture judged by year two, not week one
It is easy to ship quickly by leaving a mess. We choose structure that a developer who was not here can read, because most of the cost of software arrives after launch.
We say when the answer is not to build it
Some briefs are solved by a configuration change, a cheaper tool, or fixing the funnel that already exists. We would rather tell you that at the proposal stage than invoice for the alternative.
Claims trace back to a number you can check
Reporting reconciles platform figures with your own product data, states where they disagree and why, and is explicit when a result is too early or too thin to draw a conclusion from.
Working with us
How an engagement actually runs.
The commercial mechanics matter as much as the technical ones. These are the four things we hold constant regardless of project size.
- 01Scope in writing, before invoicing
- What is included, what is not, and what would change the price. Payment terms are set out in the applicable proposal or service agreement rather than assumed.
- 02One point of contact who knows the code
- You talk to someone who can answer a technical question directly, not to an account manager who has to relay it and come back tomorrow.
- 03Work visible while it happens
- Access to the repository, the staging environment and the reporting from the start of the engagement — not a reveal at the end of a milestone.
- 04Everything transferable at the end
- Code, infrastructure, analytics properties and advertising accounts stay with you. Handover includes the documentation needed for someone else to take over.
Who you are contracting with
A registered business, stated plainly.
Anyone assessing us — a client, a finance team, or an advertising platform reviewing an account — should be able to establish who we are without asking. So it is on the page.
- Trade name
- MNF INFOTECH
- Legal name
- NANCY GOPAL SAVALIYA
- Business type
- Proprietorship
- GSTIN
- 24HQXPB6184C1ZK
- GST registration type
- Regular
- GST registration date
- 03 September 2026
- Registered state
- Gujarat, India
- Registered office
- 1st Floor, Plot No 37Marutidham BunglowsGurukul Road, Near ABC Circle SarthanaNana VarachhaSurat, Gujarat 395006India
- Website
- mnfinfotech.com
Start here
Have a product to build, or one that has stopped growing?
Tell us what exists today and what is supposed to happen next. We will come back with what we think the real constraint is, what it would take to move it, and whether we are the right people to do it.
Directcontact@mnfinfotech.com