MST and the work beneath the screen

Imagine a customer opening a dashboard and finding two answers to the same question. Sales says one thing. Operations says another. The screen is working perfectly. Somewhere underneath it, two systems disagree about what counts. This is an illustrative problem, but it helps explain the appeal of MST’s product-and-data consulting offer: the person discussing what a tool should do might also understand why its numbers refuse to cooperate.

MST describes a services business with a compact menu. The interesting feature is the combination. Product management asks which problem deserves attention. Application development gives someone a way to act. Database work organizes the underlying records. ETL moves and reshapes information so those records can become useful elsewhere. Read together, the four offerings suggest a consultancy concerned with the journey from a business question to a working piece of software.

Four jobs, one conversation

There is a familiar temptation when buying software help: divide the assignment into tidy boxes. Someone writes the brief. Someone builds the application. Someone handles the data. The purchasing process becomes easier to describe. Whether the eventual product becomes easier to use is a separate question. A boundary that looks sensible on an organization chart can become an awkward handoff inside a project.

Consider another hypothetical buyer: a small software company wants customers to see their account activity. A developer can build the screen. But what does activity mean? A login, an invoice, a completed task? Who needs the information, and what decision follows? Those questions belong in the brief before anyone chooses a chart. They also affect which records must be collected and how they should be connected.

That is the practical attraction of putting these disciplines together. It creates room to discuss the definition and the implementation in one conversation. This is an interpretation of MST’s positioning, rather than a claim about a particular client result. The offering makes most sense when the uncertainty crosses the boundary between what the customer needs and what the existing systems can provide.

The interesting word is transform

ETL stands for extract, transform and load. The sequence takes information from its sources, changes it into a suitable form, then delivers it to a destination. AWS’s explanation describes the role of cleaning and organizing data for analysis. The middle step deserves attention. Moving a record is straightforward to picture. Deciding what that record should mean requires an understanding of the business.

Return to the imaginary dashboard. One system might count orders when they are placed; another might count them when they are fulfilled. Both totals can be internally consistent. A useful transformation has to preserve the distinction or reconcile it deliberately. Otherwise, the software simply transports the disagreement to a more attractive screen. Faster reporting does little good if the report answers the wrong question.

For a prospective buyer, this suggests a concrete exercise: choose one number that people argue about. Trace its inputs. Write down the counting rule. Ask who uses it and what they do next. That exercise does not require commissioning an application. It produces something useful to take into a consulting conversation: a specific question with visible dependencies.

A useful brief connects the decision on the screen to the records underneath it.Editorial takeaway

A person where the brochure might be

Visit MST’s website and the emphasis changes. Jim Crews’s name appears over a mountain landscape. The short first-person introduction describes a technical product specialist interested in young SaaS businesses built around data. There is ambition in the phrase “data to change the world.” There is also an explicitly personal preference for purposeful work and enjoying the people doing it.

The company’s LinkedIn profile lists it as self-owned. That framing invites a different buying conversation from a packaged software purchase. A buyer is evaluating expertise, judgment and the fit of an assignment. The SaaS reference describes the kind of business that interests the person behind the website; it should not be mistaken for evidence of an MST subscription product.

Buy the connection

Product management connects business, technology and user needs. That makes the combined brief especially useful when a technical request still contains an unresolved customer question. A buyer approaching a consultancy with MST’s stated capabilities should bring examples of real tasks, representative records and an explanation of what success would let someone do differently.

For budgeting, separate the initial investigation from the proposed build. Ask what access is needed, which decisions the first phase will settle and what deliverable will make the next spending decision easier. These are buying suggestions, not MST’s published contract terms. A fixed outcome and a defined stopping point make an estimate more meaningful than a broad request to improve the data.

Include the handover in that discussion. Ask who will maintain the application, where transformation rules will be documented and how a future teammate will know whether a changed number is expected. A successful demonstration is only one moment in a product’s life. For work involving both software and data, the continuing ability to explain the result belongs in the definition of a useful deliverable.

There are sensible alternatives. An existing application may already fit the workflow. A database contractor may be sufficient for a tightly specified repair. A permanent hire may suit continuing ownership. The combined consulting approach earns its place when the problem needs both product judgment and technical investigation. Begin with one customer task. Follow it down to the records. Then decide how much software it deserves.