Skip to main content
About

A software business and an advertising agency, deliberately

MNF Infotech is a proprietorship registered in Surat, Gujarat. It builds mobile and web products, and it operates as a digital advertising agency for the businesses that need those products found. The point of holding both is simple: the change that fixes a number is often not in the place the number is reported.

  • Proprietorship
  • Surat, Gujarat
  • GSTIN 24HQXPB6184C1ZK
What this business actually does

MNF Infotech does two things that are usually bought from two suppliers. It builds software: native Android and iOS applications, web platforms and dashboards, the backend services and APIs underneath them, and the cloud environments they run in. It also operates as a digital advertising agency, planning, buying and managing campaigns across Google, Meta and the app platforms on behalf of the businesses it works with. The measurement layer between the two, and the optimisation that follows from it, is where the combination pays for itself.

The combination is the point, not the list. A campaign cannot report on a conversion the product never emits, and an elegant architecture is worth little if nobody can be brought to it at a price the business can pay. Keeping both sides in one place means a bad return can be traced to an onboarding step or a mis-fired event rather than blamed on the ad account, and the fix can be made where it will actually work.

The problems this work is built for take a few recognisable shapes, and none of them are exotic. An app that shipped quickly and has since become expensive to change safely. An ad account spending steadily against a conversion nobody has verified since the day it was configured. A reporting stack where the tools disagree and nobody can say which of them is right. A backend that was comfortable at launch traffic and is not comfortable at the traffic it carries now. A product with real usage and no clear idea which part of it people come back for. Naming the shape is the easy half; working out which one you actually have is where an engagement here starts.

It is worth being plain about what this is not. We are not a staffing agency: you are not buying hours to direct yourself. We are not a reseller putting our name on someone else's build. We are not an AI-first business — we use language models where they beat a rule, and refuse them where a rule is cheaper and more predictable. And we do not hand over a build and disappear, because the interesting part starts once real users arrive.

What we hold to

Positions we work from

These are positions rather than values, which is a way of saying they change what gets done, not just how it is described. Each one costs us something, and each one is stated here so you can hold us to it.

  1. Measurement is part of the build, not a phase after it

    Instrumentation added after launch describes a product that has already changed. So the event model is written with the scope, the events land with the features that emit them, and each one is verified in a debug environment before release. It costs a little more during the build and it removes the argument, six months later, about whether the number is real. A feature with no agreed definition of success is not ready to be written.

  2. An architecture is judged by its second year

    Anything can be made to work once. The question is what the fifth change to it costs, and whether someone who did not write it can make that change safely. We optimise for legibility over cleverness: clear module boundaries, boring control flow, no indirection that only its author can follow. That often means the first version takes slightly longer and every version after it takes less, which is the trade we would want as the client.

  3. The constraint is rarely where the brief says it is

    A brief usually arrives with the solution already attached to it — a redesign, a new campaign, a rebuild. Often that brief is right, and the fastest thing anyone can do is agree with it and start. Often enough it is not, and the redesign is really a slow API, the campaign is really a checkout that fails on one bank, the rebuild is really three queries and an index. So the first thing we do is read what exists and test the diagnosis, before quoting for the cure.

  4. Growth is an engineering problem before it is a media problem

    Bidding systems learn from the signals you send them. If the conversion is an install, they will find you installs, including the ones worth nothing. Before touching budget we check what the product reports, what value it carries and whether the platform is receiving it — because the most valuable change in most accounts is not a bid strategy, it is a corrected event. Media buying is the last step, not the first.

  5. Saying no to work is part of the job

    We will argue against a build we do not think should happen, including one we have been asked to quote for. Sometimes the honest answer is that a spreadsheet is already doing the job, that the app should be a web page, that the campaign should wait until the product retains anyone, or that the budget is too small to learn anything. Turning down work we could bill is cheaper for everyone than delivering something that was never going to pay for itself.

Technical approach

How technical decisions get made

Most technology choices are commercial choices in technical clothing. The rules below are what we apply when the decision is ours, and what we argue from when the decision is yours.

01Boring technology, chosen on purpose
We pick tools with long histories, hiring pools deep enough that you could staff the work somewhere else tomorrow, and documentation written by people who are not us: Kotlin, Swift, TypeScript, React and Next.js, Node, PostgreSQL, Google Cloud and AWS. Novelty is spent deliberately and rarely, on the one part of a system where it buys something real. Everywhere else, predictable behaviour under load and at three in the morning is worth more than elegance.
02Build for the load you have and the next order of magnitude
Architecture sized for imagined scale wastes money now; architecture sized only for today fails in public later. So we design for current traffic and check the design survives ten times it, then write down where it would break and what the next step costs. That way the decision to spend on capacity is made deliberately, with a number attached, rather than during an outage.
03Typed contracts between every layer
Interfaces between the app, the API and the database are defined as types, generated where possible and versioned where they cross a boundary someone else depends on. A schema change that breaks a client should fail in the pipeline, not in a user's hands. Types are not an aesthetic preference here; they are the cheapest test suite available and the closest thing to documentation that cannot go stale.
04Performance and accessibility are acceptance criteria
A page that fails Core Web Vitals on a mid-range Android phone is not finished, and neither is a screen a keyboard cannot reach. Budgets for load, interaction and bundle size are agreed with scope, contrast and focus order are decided during design, and both are checked before a release is called done — not filed as improvements for a quarter that never arrives.
05Environments and secrets stay outside the code
Development, staging and production are separate projects with separate data and separate credentials, so a test cannot write to a live table and a leaked key cannot reach real users. Secrets live in a managed secret store or the platform's environment configuration, never in the repository and never in a chat message. Access is granted per person and per environment, and revoking it is a single action.
Client relationships

How we work with clients

Engagements start with a written scope: what is included, what is explicitly not, and how we will both know the work is finished. Changes to that scope are written down too, with their cost and their effect on sequence, before they are started. This is less about protecting anyone contractually than about removing the slow, expensive disagreement that begins when two parties remember the same conversation differently four months later.

Everything is built in your accounts. Repositories, cloud projects, ad accounts, analytics properties, signing keys and domains are created under your ownership from the start, with us added as a member at the access level the work requires. Nothing depends on a machine or a login of ours. If the engagement ends tomorrow, you keep working, and removing our access is a matter of revoking the invitations you issued rather than a migration project of its own.

Reporting is written to be argued with. It says what moved, what did not, what we changed and what remains unknown, and it uses the same definitions month after month so the comparison is real. When a test fails or an estimate was wrong, you hear it from us first and early, with the revised plan attached. One person is answerable for the engagement and replies from a named address, so nothing is lost between a form and a queue.

What we commit to

  • Every account, repository and key is created under your ownership; we are added as a member, never as an owner.
  • Our access is scoped to what the work needs and can be revoked by you at any moment, without breaking anything.
  • Scope, exclusions and acceptance criteria are written down before work starts, and changes to them are written down too.
  • One named person is answerable for your engagement and replies from a real address, not a ticket queue.
  • Reporting says what did not work as plainly as what did, and reaches you before you have to ask.
  • We hold no partnership, certification or affiliation with any platform, so our advice answers to you alone.
Business identity

The registered facts, in one place.

Anyone assessing this business — a client, a finance team, an advertising platform reviewing an account — should be able to establish who we are without having to ask.

MNF INFOTECH is a proprietorship owned by Nancy Gopal Savaliya. It is not a private limited company, not an LLP and not part of a group, so it has no CIN or LLPIN. The registration below is the whole of it.

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

Where we are registered, and how the work is delivered

MNF Infotech is registered at 1st Floor, Plot No 37, Marutidham Bunglows, Gurukul Road, near ABC Circle Sarthana, Nana Varachha, Surat, Gujarat 395006, India. That is the registered and principal place of business on the GST record, and it is the only one. There are no branches and no second office, in India or elsewhere, and we would rather say that plainly than imply a footprint that does not exist.

The work itself is delivered remotely. Code lives in your repository, infrastructure in your cloud account, campaigns in your ad account, and the conversation happens over email and scheduled calls in whatever timezone suits you. Clients in India and clients abroad are handled the same way, so being registered in Gujarat constrains nothing about who we can work with. Where a project genuinely needs someone physically in the room, we say so rather than pretend distance costs nothing.

Questions

About the business itself

01Who owns MNF Infotech?

MNF Infotech is a sole proprietorship owned by Nancy Gopal Savaliya, who is the proprietor named on the GST registration. There are no shareholders, no partners and no parent business. The trade name MNF INFOTECH and the legal identity of the proprietor refer to the same entity, which is why contracts, invoices and the GST record all carry both. If you need this confirmed for onboarding, ask and we will send the registration details.

02What is the legal form of the business?

A proprietorship, registered in Gujarat, India. It is not a private limited company, an LLP or any incorporated body, so it has no CIN and no LLPIN — those identifiers do not exist for this constitution, and any listing that shows one for us is wrong. The identifiers that do exist are the GSTIN and the proprietor's name, both of which appear on our invoices and in our contracts.

03Is the business registered for GST?

Yes. MNF INFOTECH holds GSTIN 24HQXPB6184C1ZK under the Regular scheme, registered on 03 September 2026, with the principal place of business at the Nana Varachha address in Surat. Invoices are raised as GST tax invoices carrying the GSTIN, which is what registered Indian clients need for their own input credit claims. The details are on the government portal if you would rather verify them yourself.

04Can you work with clients outside India?

Yes. Work is delivered remotely, and an overseas engagement differs mainly in paperwork and scheduling rather than in how the project runs. Contracts can be denominated in a foreign currency, export of services is invoiced accordingly under Indian GST rules, and calls are arranged in your working hours rather than ours. What we ask for is a single decision-maker on your side and written scope, which matters more at distance than it does locally.

05Are you a Google Partner, or certified by any platform?

No. We are not a Google Partner, not certified, authorised, affiliated or endorsed by Google, Apple, Meta, Amazon or anyone else, and we would not claim otherwise to win work. We use those platforms as any advertiser or developer does, and their names appear on this site only to describe products accurately. The advantage of holding no badge is that our advice about a platform answers to you rather than to a programme.

06How do you handle confidential material?

We sign your NDA, or ours if you prefer one. Access to repositories, cloud projects and ad accounts is requested at the minimum level the task needs and removed when the engagement ends. Credentials are never accepted by email or chat; we ask to be invited as a member instead, so nothing is shared that cannot be revoked. Production data is not copied to local machines when anonymised or synthetic data will do.

Next step

Tell us what is actually stuck

Send the problem as you see it, along with whatever exists already — an app, an account, a spreadsheet, a half-finished build. You will get a straight reading of it, including if the answer is to do nothing.

Directcontact@mnfinfotech.com