Skip to content

Find your next step.

Explore the studio

Custom Business Software for Kolkata

Turn the operating brief into software people can use.

Softglimmer plans and develops custom business software for Kolkata teams whose work needs clearer records, decisions and coordination. The service connects discovery, interface design, application development, selected integrations and an operating handover. We deliver remotely from our Ranchi studio. The starting point is your real process and the people responsible for it, rather than an assumption that every existing tool must be replaced.

Explore the scope
From a practical process brief to an application with reviewable responsibilities.
  1. 01

    Map the work

    Follow the record and its decisions.

  2. 02

    Define the release

    Agree roles, data and useful behaviour.

  3. 03

    Prepare operation

    Make ownership and support explicit.

An example journey, shaped around your requirements.

Commission an application around a defined business responsibility.

Start with a piece of work that people need to complete: a request, an internal review, a job record or another recurring process. Identify what enters the process, which decisions change it and who needs the result. The aim is a shared understanding of the operation before the team commits to screens and features.

A full custom-software scope can include discovery, data and permission design, a usable application, agreed connections to existing tools, acceptance checks and deployment planning. The first release should still cover a complete useful journey. A narrow screen that leaves staff to reconstruct the underlying record is different from a bounded application they can operate. We agree what stays manual and which later requirements remain outside the release.

Choose how the problem should be solved.

The preferred route follows the workflow and the existing systems.

01

Configure, connect or build

An existing product may already support the task with suitable configuration. A connection may remove an isolated handover gap. A custom application becomes a considered option when the required records, decisions or interfaces need their own implementation. Compare these routes against the same representative work.

02

Define the people and the boundaries

Separate a person’s job title from the actions the application should permit. Agree who can view, enter, approve, correct and export the relevant information. The business supplies its rules and designated reviewers; the software brief records how those rules become usable behaviour.

03

Decide what each connection owns

List the systems involved, the information exchanged and the authoritative owner for each action. Access, interface availability and failure handling need review before a connection is promised. Replacing a system or moving its data is a separate decision with its own operating consequences.

What an agreed software project can include.

The proposal makes the application boundary and acceptance material concrete.

01

Workflow and requirements map

A documented process identifies entry points, roles, decisions and exceptions. Representative records expose where people interpret the current process differently. The map distinguishes required behaviour from suggestions for a later phase and gives business reviewers something specific to approve.

02

Data and permission model

Agreed field meanings, record relationships and role actions form the basis of the application. We identify required information and legitimate incomplete states. Where history, corrections or exports matter, their purpose and availability belong in the specification rather than being inferred from a dashboard.

03

Role-based interface and application

The build implements the selected tasks with readable forms, useful views and clear feedback. Reviews include empty, incomplete and unsuccessful journeys alongside the ordinary completion path. The interface should help the responsible person understand the record and the next permitted action.

04

Selected integrations or migration

Where included, we map the fields and operations shared with existing systems. Sample data and agreed access help establish the connection’s scope. Imports and migrations need review of rejected or unmatched records, with a clear decision about who resolves an exception.

05

Acceptance and deployment plan

The review set follows important tasks through the application and checks the resulting records. The plan identifies the test environment, release responsibilities and any business conditions required before use. Hosting, backups and recovery checks are agreed as operating work, with responsible owners.

06

Documentation and handover

The handover records application access, deployment responsibilities and instructions for the agreed tasks. It identifies who receives issues and how changes are assessed. Source, account and third-party ownership arrangements are made explicit in the proposal; continuing support has its own defined terms.

Make progress visible through working decisions.

Review the process and the application together.

  1. 01

    Discover the current operation

    Bring people who perform and review the work, plus redacted examples from the tools they use. We record disputed meanings and dependencies before turning them into implementation assumptions. Discovery can identify a useful existing-tool option as well as a custom-build opportunity.

  2. 02

    Review the model and interface

    Use sample records to inspect the planned data, roles and important screens. Ask each reviewer to complete a task and explain the result. This gives the team a better basis for feedback than reviewing isolated dashboard decoration.

  3. 03

    Build and verify the release

    Implement the agreed journey and selected connections. Acceptance covers ordinary records and the specified exceptions, including what the user sees when an action cannot complete. Record the outcome of each review and distinguish unresolved requirements from defects in the agreed scope.

  4. 04

    Prepare use and improvement

    Confirm release access, the operating owner and the material needed for staff to begin. Plan any data transition with the people responsible for the source. Later enhancements can then be assessed against an understood application rather than an unbounded promise of every future feature.

An optional example: zero is not the same answer as “not known”.

Imagine a team recording the number of replacement items used on a job. A completed review can legitimately record zero. A different job has not yet been checked. If both appear as zero in the application, a supervisor cannot distinguish a confirmed result from a question still awaiting an answer. This is a hypothetical discovery example, not a Kolkata client system.

The brief could define a quantity together with the review state that gives it meaning. A user should be able to record an approved zero without inventing a positive quantity, while an incomplete record remains recognisable. Decide what summaries include and how they label excluded records. The business must approve those meanings; replacing an empty field with a convenient number would not settle the operating question.

Prepare examples that show how the work really happens.

Share the current forms or spreadsheets, redacted records and a list of the people who make decisions. Include an ordinary completed case, one with missing information and one that required correction. Explain which reports staff actually use and what action follows each report.

For Kolkata and Ranchi remote reviews, agree India-time sessions and a business contact who can consolidate decisions. Identify current system owners early, particularly where access or an external interface is needed. Costs and milestones can then follow the agreed records, roles, integrations and acceptance cases. Uncertain data or undocumented connections may need a focused investigation before implementation is estimated.

A documented reference for organising complex information.

KMS Consultancy is a website project in our portfolio, presenting a complex compliance service catalogue through clear pages and an enquiry journey. It is a useful public information reference. The custom application, its private records and operating rules would be a separately scoped software commission.

ContentCompliance
StructureService pages
ActionEnquire
KMS Consultancy websiteKMS Consultancy

Questions before starting a software brief.

Can you work with our Kolkata team remotely?

Yes. Our studio is in Ranchi and delivery for Kolkata is remote. We agree review sessions and use representative material with named business approvers. The project plan records responsibilities and access arrangements.

Do we have to replace all our existing tools?

No. We compare configuration, a supported connection and a custom application against the same process. Useful systems can remain in place. Any replacement needs a reason and an explicit plan for data, users and operating responsibilities; it is not an automatic consequence of commissioning software.

Can we begin with one department or workflow?

A focused first release can be useful when it completes a meaningful journey and its dependencies are understood. We define the roles, records and acceptance tasks for that boundary. Other departments and later features remain visible in a separate backlog so the first release has a reviewable purpose.

What determines the price and support arrangement?

The data model, role actions, integrations, migration requirements and acceptance work shape the estimate. Unknown interfaces or source data can affect the plan. Support duties, availability, hosting and future changes are agreed explicitly; there is no universal price or service-level commitment implied by this page.