Public sector

Portals procurement can actually review

Citizen and staff services, API façades over legacy systems, and cloud baselines with written SOWs. We take documentation seriously; we do not claim to run government programs.

A 40-country delivery map is not a portal.

You have seen the bid that promises transformation in a hundred pages. Then someone has to ship a form, sit with the legacy system, and still be around when procurement asks who owns the source. That second part is the job.

Myrafy is a software company in Noida. We take one portal or one façade into production, keep the people who scoped it on the work, and put the code where you can keep it.

What we put in a statement of work

Pick the service residents or staff will actually complete.

01The form someone finishes on a phone

Citizen and staff portals

Calm, accessible screens for the jobs that already happen: applications, status, the unglamorous admin. Built against the process you have, not a greenfield agency.

  • Roles from the first screen
  • A path a resident can complete
  • Weekly demos until it is in use
02A contract in front of the system that still holds the record

API façades over legacy

Jobs and APIs beside the core you cannot turn off. Phased. The old screens stay up until the new path is boring.

  • The legacy system stays the book if it holds
  • A written fail path
  • No weekend cutover
03An environment procurement can review

Cloud baselines you can explain

Accounts, a pipeline, and something watching it - in infrastructure you control. Useful when deploys still live on one laptop.

  • Your account, not ours
  • Access and logging from the start
  • A runbook a new engineer can follow
04The artifact reviewers actually read

Documentation that matches the SOW

Architecture notes, access, and how to run it - written for the people who were not in the room, not a slide that says complete.

  • Acceptance in writing
  • Decisions that would otherwise live in chat
  • Full IP on delivery

The framework is usually not the hard part.

This dies in a bid nobody can accept, a legacy owner who is not on the call, and source that never quite lands. We start there.

01

Unwritten acceptance

The RFP wants everything. Nobody named done.

  • A 200-page wish list
  • No owner for the citizen path
  • A deadline with no rollback

We cut to a slice a reviewer can accept. Discovery can be a paid slice if the process is still fuzzy.

02

Legacy without a room

The people who know the core are not on the call.

  • Spec in one tool, records in another
  • QA as a surprise at go-live
  • A cutover that cannot roll back

We keep one engineering thread and insist the system-of-record owners stay until the façade is accepted.

03

Source as a rental

The portal is hosted in a toolkit only the vendor understands.

  • Deploy knowledge in one head
  • No runbook
  • IP that never quite lands

If you cannot build it the week after we leave, we did not finish. Repos, docs, and how to run it stay with you.

Two ways to start

Most teams pick one. Neither needs a 40-country delivery map first.

01If the first service is clear

Fixed-scope portal or façade

A citizen form, a staff tool, an API in front of legacy. Written inputs and acceptance. Weekly demos. Full IP when the milestone closes.

  • Best when procurement can name the slice
  • The same engineers through release
  • Documentation reviewers can read
02If the legacy core will take more than one SOW

Phased modernization

A dedicated slice of senior time next to your IT team. Useful after the first path is live.

  • A cadence you can plan around
  • Still a written SOW
  • You keep the source

Name the service, build next to legacy, ship it, and leave you able to run it.

Four steps. We will not promise to replace the agency from a kickoff.

  1. 01

    Name the service

    Sit with the people who do the work. Name the first citizen or staff path, the legacy it touches, and what done looks like.

  2. 02

    Build next to legacy

    Against your APIs and data. Access and logging from day one. The people who scoped it are still on the calls.

  3. 03

    Ship a path people complete

    A release in an environment you control. Not a staging portal that dies when the project ends.

  4. 04

    Leave you able to run it

    Runbook, access, and how to keep shipping. If the work continues, that can be a later SOW.

What we write into every SOW

  1. 01

    Acceptance is written

    If we cannot say what done looks like, we are not ready to start. Discovery can be a paid slice if procurement is not there yet.

  2. 02

    Legacy stays up until the new path is boring

    No weekend cutover of the system of record. Rollback is named in the SOW.

  3. 03

    Your repo

    Code lands where you can keep it. We do not trap a public service in a private toolkit only we understand.

You contract us. You keep the IP.

The commercial bit, without invented win rates. We will publish customer stories when we have permission.

  1. 01

    Written SOW

    Inputs, owners, acceptance, and the fail path before we start. Fixed-scope when the slice is clear. Retainer when it will keep growing.

  2. 02

    Senior engineers on the work

    The people who scoped it stay on delivery. 15+ years collective experience. You will not get a junior bench behind a slide.

  3. 03

    You own it

    Code, docs, and runbooks transfer to you. We do not lock this in a product only we can run.

  4. 04

    Estimate in one business day

    Typical reply from Noida the next working day. If the workflow is still fuzzy, discovery can be a paid slice.

What you receive at handover

01

A running service

The portal or façade in the SOW, in an environment you control.

Handover checklist
  • 01A running service
  • 02The source
  • 03How it is put together
  • 04How to run it
Transferred to you
02

The source

Repos, history, and enough structure that the next engineer is not lost.

03

How it is put together

Architecture notes, access, and the decisions that would otherwise live in chat.

04

How to run it

Deploy path, who to call, and the IP. You own it.

Examples of this work

Shapes, not named clients yet. If yours is close, we will write a proposal around your constraints.

Representative patternCitizen services

A portal a resident can finish on a phone

One application path with status, roles for staff, and documentation procurement can review. Weekly demos and full IP when the milestone closes.

  • Written acceptance
  • Weekly demos
  • Full IP

Representative patternLegacy façade

An API in front of a system you cannot turn off

A contract other services can call, with the old screens still up until the new path is boring.

  • Phased
  • A written fail path
  • A runbook

More shapes on representative work →

Questions we get

What we usually use

We use what is already in your stack when we can. This is not a vendor lock-in.

  • Legacy Migration
  • API Strategy
  • Cloud Migration
  • Refactoring
  • Java
  • Node.js
  • .NET
  • React
  • PostgreSQL
  • AWS
  • Azure
  • Kubernetes
  • Terraform
  • Docker

Have a public service to ship?

Send the path and the legacy it touches. We usually reply with an estimate the next business day.

Get a Free Estimate
Contact us