MK Solutions: When the Bill Touches ISP Broadband

Summary

MK Solutions' strategic value does not lie in any single module. It lies in the attempt to maintain a single subscriber record across sales, FTTH feasibility, provisioning, billing, collections, support, inventory, analytics, and field work.
This integration can reduce duplicate entries and shorten fault resolution cycles, but the same shared data can propagate a bad address, plan, tax rule, network identifier, or payment status across the ISP. Data migration and governance are therefore part of the product, not preliminary tasks.
Public documents reveal a profitable vertical software business, while public pricing, current audited customer counts, service level commitments, and detailed security warranties remain unavailable. Marketing and result figures must be treated as claims until validated by a buyer.
Procurement should test the exact contracting entity, the actual workflows, banking and OLT dependencies, incident evidence, support escalation, and a full export and rebuild exercise. A platform that becomes an ISP’s control plane must prove not only that it can run the operation, but that the operator can recover and exit.

The unpaid bill that crosses the network

Let’s start with an ordinary event: a residential subscriber does not pay by the due date. In a loosely assembled set of suppliers, this event can exist separately in a bank return file, an accounting system, a customer spreadsheet, an authentication platform, and a support agent screen. Someone reconciles identities. Someone decides whether a reminder has been sent. If the service status changes, another system must know. When the subscriber pays via Pix and calls for restoration, the payment, the contract, and the network session must all align.

Each handoff is a small opportunity for delay, duplicate work, or an angry customer who has already paid.

MK Solutions’ proposition is that these handoffs can be organized around the same operational record. Itspublic ERP documentslink contracts, invoices, accounts receivable, collections, technical authentication, traffic information, outage alerts, service orders, stock, and a technician application.MK BotandMK SAC+expose selected actions to messaging channels and self-service.MK Agentes+carries subscriber, equipment, and provisioning information into the field.NextPaycoordinates collection and payment functions. The analytical term “control plane” describes the operational role this combination seeks; it is not a claim that MK has published a particular network control architecture.

The distinction matters. MK does not own the ISP’s access network simply because its software can document a splice box or send provisioning instructions. It does not become the subscriber’s bank because its payment layer can issue a Pix charge. Nor does an integrated screen guarantee that every underlying record is correct. What it can do is make a financial state operationally visible, put a technical state in front of support, and feed a field action back into inventory. For a regional ISP with lean teams, this continuity is potentially more valuable than a single trendy feature added in isolation.

This is also why a conventional software comparison is limited public evidence. A buyer must ask what happens when the banking API expires, an address is geocoded against the wrong terminal, a tax document is rejected, an ONU command fails, a technician loses connectivity, or a migrated customer has two active contracts. The strongest version of the MK case is that the suite closes these loops. The strongest objection is that a single platform then sits inside nearly every loop. The rest of the evaluation follows from this concentration.

The legal entity behind the MK name

The entity examined here isMK SOLUTIONS CRIAÇÃO DE SOFTWARE LTDA, CNPJ09.587.408/0001-86, not a generic “MK” brand, an investor, or a later corporate shell. MK’spublic privacy policyexpressly names this company and registration number. Thecompany’s own historysays the founders first ran an ISP and turned their in-house solution into a commercial product in 2008. This origin story is plausible and consistently repeated, but remains a corporate narrative.

The current website footer and the March 2026 corporate notice both list Rua Daniel Caspary 85 in Santa Cruz do Sul. The original privacy notice still shows Rua Guilherme Werlang 105. Recruitment pages associate positions with Santa Cruz do Sul and, at various times, with Porto Alegre, São Paulo, and Belo Horizonte, while the “About” page describes a distributed workforce. A workplace is not evidence of a permanent branch, and no current authoritative branch list has been identified.

The defensible public description is therefore an operational base in Santa Cruz do Sul plus a company-claimed distributed coverage—not a verified national office network.

Ownership is better documented. Financial statements filed with Brazil’s Central de Balanços indicate thatTBG Investimentos e Participações acquired MK in 2020and held full ownership during the covered periods. The statements describe MK as software for telecommunications providers. A contemporary report inExameattributed a R$30 million investment plan in 2022 and growth targets to management. These targets illuminate ambition, not achieved results.

The boundary becomes less clear after that. Acorporate notice published in July 2025 in Jornal O Diaconvened a TBG meeting to consider incorporating MK Solutions Criação de Software Ltda into TBG and proposed changes to TBG’s name, corporate purpose, and address. In March 2026, anotherpublished corporate noticereferred toMK Solutions Tecnologia S.A., CNPJ 30.420.144/0001-68, at the same Rua Daniel Caspary address used by the operational brand. These notices are strong evidence of a reorganisation process and a successor corporate vehicle. They do not alone answer all questions about the effective date, transfer of each contract, or the continuing status of CNPJ 09.587.408/0001-86.

A separate transaction adds another layer without resolving it. In September 2025, US-listed Nuvini announced in anSEC Form 6-Ka binding letter of intent to acquire MK, subject to due diligence and closing conditions. AForm F-3from January 2026 still described the transaction as conditional. Nuvini’s subsequent2025 annual reportrevealed that the seller alleged a breach in March 2026, which Nuvini contested. The public record therefore doesnotallow stating that Nuvini completed the acquisition.

For an article, the disciplined response is to retain the assigned entity boundary and report the subsequent filing. For a buyer, this is a closing condition: obtain an up-to-date Receita certificate, the incorporation instruments, proof of authority, the exact CNPJ on the proposal and invoice, and a written allocation of intellectual property, hosting, support, confidentiality, and continuity obligations. A familiar logo and an unchanged office do not replace knowledge of the legal entity that owes the service.

Scale in a fragmented broadband market

MK’swebsitecurrently states that it serves more than 2,500 active customers, connects more than 15 million Brazilians through its systems, and is used by 32 of the country’s 100 largest providers. Its “About” page says employees are spread across more than 12 states. These figures establish what MK wants the market to believe; the pages do not provide a dated customer list, computation method, or independent assurance. Exame reported in 2022 that MK said it was present in 25 of the 27 states and managed 30% of Brazilian connections. That older claim cannot validate today’s different metrics.

The addressable market is nonetheless significant and unusually distributed. TheTIC Provedores 2024 studyby Cetic.br of NIC.br estimated 11,853 Internet access provider companies in Brazil in 2024. Forty-one percent operated in a single municipality and 45% were micro-enterprises. TheTIC Domicílios 2024 studyfound fixed broadband in 71% of connected households, with cable or fibre as the dominant fixed access type. These surveys do not measure MK’s share. They explain why a vertical system can matter: thousands of operators must perform similar billing, customer, network, and regulatory work despite large differences in size and professional capacity.

Anatel itself stated in aJune 2025 enforcement planthat small providers represented more than 53% of fixed broadband accesses in 2023, while reporting failures remained widespread among authorised companies. In May 2026, the regulator describedmarket consolidationas a natural step in a fragmented sector under margin pressure. This context rewards systems capable of standardising work across a growing provider. It also means that a software vendor’s “typical customer” may be misleading: a single-city operator, a multi-state consolidator, and a 100,000-connection provider do not share the same controls, integrations, or support load.

One subscriber, many operational consequences

The best way to understand MK’s scope is to follow a customer rather than browse its menu. A potential subscriber entersMK CRM+. The public documentation indicates that the application can collect identity documents and photographs, obtain GPS location, verify FTTH feasibility against mapped cabinets within a configured radius, select a plan, and create the information needed for installation. This combines sensitive personal data, a commercial decision, and a network capacity decision before service begins.

Installation can become a field work order. Agentes+ documentation indicates that authorised technicians can view subscriber information, access credentials, and equipment identifiers, move inventory, and perform actions including ONU provisioning. MK Maps provides the network record that gives context to these actions. Once active, the technical domain of the ERP can associate authentication, connection time, bandwidth usage, routing information, and outage alerts with the subscriber. Finance produces charges, tax documents, and receivables.

A support workspace links tasks to service level rules, while SAC+ can display invoices, consumption, contracts, and tickets to the customer. Bot integrations can answer common requests or move them into an agent queue.

This sequence is more than convenience. In a well-governed implementation, the sales promise can be tested against actual capacity before a contract is signed; the installed ONU can be matched to stock; the active plan can become the billed plan; a payment can update the status visible to support; and a field replacement can close both a service order and an inventory movement. Managers can then use BI dashboards built on operational transactions rather than asking each department for a spreadsheet.

Public evidence does not prove that every module writes to a physically unified database, that changes propagate in real time, or that all integrations are transactional. MK publishes product pages and task-level documentation, not a complete system design. “Single record” must therefore be read as the desired operational continuity, not a verified claim about storage topology. In procurement, the difference is testable.

Change a plan, the customer address, the due date, the ONU, and the splice port assignment in a sandbox; then inspect which screens, APIs, audit logs, and reports change, in what order, and how a failed downstream action is reconciled.

It is also necessary to resist the happy demo path. A lead may have a mistyped CPF. Two streets may share a name. The mapped cabinet may show a free port that a technician already used offline. A contract may be signed while a banking profile is invalid. A payment webhook may arrive twice or not at all. A subscriber may have two properties and only one WhatsApp number. The value of integration appears in how the suite handles these exceptions—not in how quickly a fresh lead turns into a green status icon.

What the public architecture shows—and does not show

MK offers enough technical documentation to reveal significant operational surfaces, but not enough to complete an architecture review. The company indicates that the ERP can run in the cloud or on physical servers. Its API documentation describes token-based access, permission profiles, and endpoints for leads, plans, contracts, invoices, and service orders. Ageneral API guidedescribes web service profiles and a 90-day log view. Aspecial APIs pageindicates that certain write operations require an additional environment and a commercial contact. AnInsomnia proceduredemonstrates token acquisition and permission setup.

This is practical evidence that MK is not a sealed application. It can expose basic business entities and allow external systems to act on them. MK’s website claims more than 100 integrations and more than 50 partners, while its FAQ gives a different figure of more than 50 native integrations. Neither number is accompanied by a versioned catalogue or availability history. A third-party integration guide fromOpa! Suiteis more concrete: it instructs the ISP to obtain an MK endpoint and multiple credentials so the service can retrieve contracts, invoices, and diagnostic or unlock functions. AZapisp gateway guideshows messages generated by MK being forwarded to a WhatsApp service. These examples demonstrate real-world integration, but also the propagation of privileged credentials between providers.

Several important design facts remain unpublished. The documents examined do not establish the current database engine and supported versions, tenant isolation model, encryption-at-rest coverage, key custody, regional hosting locations, queue and retry semantics, API rate limits, immutable audit retention, recovery point and time objectives, mobile offline conflict handling, or software bill of materials. They also do not show whether all currently marketed modules share the same authentication and authorisation service. None of these gaps prove a weakness.

Each is a demand for proof that a serious buyer should resolve under confidentiality before depending on the suite.

Updates are an operational event, not a background abstraction. MK’sERP update guidestates that versions are deployed after testing, can be initiated or scheduled by the customer, interrupt web access for operators, and have an estimated window of 30 minutes. This is useful transparency, but it is not a uptime SLA. A provider should ask which functions continue during the window, how field applications and automated collection queues behave, whether a version can be rolled back, how migrations are backed up, and what happens when a customer defers an update required by a bank, tax authority, or security patch.

A map is not a fibre network

MK Maps is where the control plane description can most easily become misleading. The productdocuments FTTH infrastructure: cables, splice boxes, ports, splitters, customers, and signal information. It can make cabinet capacity visible to CRM, generate or store scripts related to the OLT, show a splice diagram and history, and allow a field user to provision an ONU. These records can reduce blind interventions and make feasibility decisions more disciplined.

They do not give MK ownership or physical control of the provider’s fibre, ducts, poles, OLTs, or customer premises. The ISP owns or contracts these assets and remains responsible for the accuracy of the digital representation. A command prepared via an application still reaches the provider’s specific network equipment through interfaces that the provider configures. Signal values are observations, not proof that a route has no degradation. A drawn cable is not evidence that a crew installed it exactly there.

This is the classic digital twin compromise at a modest scale: the map becomes valuable as people trust it, and people only trust it if every build, splice, relocation, and decommissioning is recorded. Integration amplifies both directions. A correct cabinet record prevents a salesperson from promising an impossible installation. An incorrect capacity record can create a bad contract, an unnecessary technician dispatch, and an inventory discrepancy in a single sequence. Procurement should therefore include a sampled physical audit—selected routes, cabinets, ports, ONUs, and warehouse items reconciled with MK—not just a screen demonstration.

Permissions and history are equally important. MK indicates that Maps supports access control and activity records. A buyer should verify whether history is append-only, how long it is retained, whether bulk imports identify their actor, how deleted network elements are recovered, and whether a technician can both modify a topology record and approve the resulting inventory movement. In an integrated suite, segregation of duties matters precisely because one action can cross departmental boundaries.

The integration dividend has a data bill

The economic case for integration is intuitive. Duplicate entries decrease. The same contract does not need to be reinterpreted by billing, support, and field teams. A manager can link arrears to service status or installation performance without commissioning a custom data project. Small providers gain workflows that would otherwise require specialists. Larger groups can impose common categories and controls across acquired operations.

MK attaches specific claims to this story. Its homepage promotes productivity, retention, and arrears reduction improvements; itscase study pagefeatures figures such as a sevenfold return and significant annual bot savings. These are provider-selected claims without disclosure of baselines, sample definitions, calculation periods, or counterfactuals. They may be true for the showcased customers and poor forecasts for another operator. A buyer should ask for the raw numerator and denominator, deployment scope, starting maturity, excluded costs, and permission to speak privately with comparable customers.

Integration also creates a data bill that must be paid continuously. Customer identity requires deduplication. Product catalogues require controlled names and tax handling. Network resources require stable identifiers. Bank reconciliation requires idempotent transaction references. Inventory requires units, locations, and custody. Personnel need roles that reflect actual tasks. If these disciplines are absent, a suite does not eliminate fragmentation; it places inconsistent meanings closer together.

The riskiest migration mistake is often not a missing line, but a line mapped to the wrong semantics. “Active,” “installed,” “authenticated,” “billed,” and “paid” are different states. So are “cancellation requested,” “service suspended,” and “contract terminated.” A migration that compresses them can produce clean totals and wrong operations. The acceptance plan should reconcile cohorts across states, not just compare aggregate subscriber counts and receivables. It should also retain original evidence long enough to explain subsequent disputes.

Migration is part of the product

MK’s recruitment material is revealing because it includes migration and support roles, not just software development and sales. The company’scareers pagehas advertised migration analyst and tax support positions in Santa Cruz do Sul alongside infrastructure and commercial roles in other cities. This does not establish employee counts, staff ratios, or availability. It shows that converting customer data and interpreting Brazilian tax operations require organised human labour.

The provider contributes at least as much. It must extract from the legacy ERP, spreadsheets, RADIUS or authentication systems, network maps, warehouses, tax systems, and payment providers. It must decide which system wins when two disagree. It must map plans and discounts, normalise addresses, preserve contractual evidence, link equipment identifiers, and distinguish credit from unapplied receipts. A migration team that waits for “clean data” will wait forever; a team that silently corrects ambiguous data can fabricate liabilities.

A sound programme starts with profiling and a written mapping catalogue. It repeats several conversions, records rejected and transformed rows, and validates samples with finance, network, customer service, tax, and field teams. It runs old and new calculations in parallel for at least the risk cycles: invoices, Pix and boleto returns, tax documents, suspensions and reinstatements, inventory changes, and regulatory reports. The go-live decision should depend on agreed exception thresholds, not a ceremonial date.

Support then becomes part of continuity. MK indicates that support is free, unlimited, and available 24 hours a day. A2023 ClienteSA reportrelayed company figures that average wait time fell from 48 to 27 minutes in 2022 and average resolution time from 72 hours to six; it also cited a Pro Telecom customer manager praising support. This is more informative than an anonymous testimonial, but remains a promotional report based on company metrics and one named customer. It does not define severity levels, clock rules, exclusions, or remedies.

The buyer should ask for the actual support contract: response and restoration targets by severity, phone and off-hours channels, escalation to engineering, incident communication cadence, Portuguese coverage, named integration contacts, peak staffing during tax periods, banking integration ownership, and service credits. It should examine anonymised tickets similar to its own profile. “Local support” is not simply a domestic phone number; it is enough trained staff, with access to product engineering, to interpret the tax, network, and customer context of a Brazilian provider under pressure.

The quiet economics of a vertical ERP

MK does not publish a simple price list for the entire suite. Public documents promote modules, cloud or physical server deployment, integrations, and included support; they do not disclose a standard subscription unit, minimum term, integration fees, migration fees, API usage rights, payment processing rate, infrastructure allowance, or exit assistance. The special APIs documentation directs some users to a commercial contact. Consequently, no credible public calculation can indicate what a representative ISP pays.

Nonetheless, corporate documents reveal why the company attracts capital. Nuvini’s January 2026 F-3 included historical MK figures, in thousands of reais, for transaction modelling. It showed net operating revenue of R$31.679 million in 2024, gross profit of R$28.404 million, operating income of R$18.534 million, and net income of R$15.867 million. For the first half of 2025, it showed revenue of R$15.724 million and net income of R$6.775 million. Simple division gives a 2024 gross margin near 90% and an operating margin near 59%.

These are calculations from filed figures, not management forecasts, and the filing notes that its transaction presentation is illustrative. They should not be projected.

The balance sheet in the same filing reported R$7.508 million in intangible assets at end-2024 and R$9.060 million at end-June 2025. A preliminary transaction allocation placed the proposed consideration at R$71.5 million and goodwill at R$55.855 million. This preliminary goodwill is an accounting acquisition estimate, not the value of a separable product or customer contract. Nevertheless, the disclosed margins and proposed premium are consistent with the appeal of a specialised recurring software base whose product can be reproduced more cheaply than it can be replaced at each customer.

This last point is an inference, not a disclosed pricing model. The filings do not separate recurring licences, professional services, payment revenue, or modules, and they do not publish churn, net retention, average contract value, or customer concentration. A suite can carry high accounting margins while an individual deployment has substantial migration, training, and internal administration costs. Buyers should model total cost per connection and per business process, including their own staff, hosting, banking, messaging, third-party connectors, upgrades, test environments, and eventual extraction.

Commercial design also affects dependency. A low base price can be offset by paid modules or transaction fees; a high bundled price may include support and integrations that reduce external spend. Without the actual proposal, no conclusion is justified. The procurement comparison should place each competitor on the same workload, growth curve, module set, and five-year cash basis—and require revaluation rules for acquisitions, dormant subscribers, seasonal connections, and large migrations.

Payments are direct—and always dependent

Payments transform software integration into a daily cash-flow concern. MK presents NextPay as a collection layer for Pix and boleto, white-label communication, credit checks, negative listing flows, and automated reminders. A product page states that more than R$50 million is transacted monthly; the main site mentions more than R$500 million processed and millions of paid collections. The pages do not specify measurement dates, whether figures overlap, or whether “processed” means initiated, settled, or reconciled. Treat them as marketing scale indicators, not audited payment volume.

MK’s technical documentation gives a more useful picture. APix Sicredi guiderequires banking integration, customer credentials, certificates, DNS and webhook configuration, and indicates that funds are deposited directly into the ISP’s account. A broaderPix guidelists several supported banks. ASicoob migration guiderecords the need to migrate when a bank retires an API version. Thepayment centre documentationanticipates errors when a banking API is unavailable.

This evidence supports a nuanced conclusion. MK can centralise payment orchestration and reconciliation while settlement remains with the ISP’s financial institution; the public documents do not establish that MK takes custody of customer funds. Yet direct settlement does not remove dependency. Collection relies on banking credentials, certificates, webhook delivery, DNS, API versions, messaging channels, and the mapping between a settled transaction and the correct receivable. The control plane concentrates operational response even when financial custody is distributed.

Pix is not an optional edge case in Brazil. The Central Bank’sPix statisticsshow more than 170 million individual users and billions of monthly transactions. An ISP should therefore test duplicate reminders, delayed notifications, partial refunds, expired charges, payer name mismatches, bank unavailability, certificate rotation, and reconciliation after a failover. It should know which party opens the banking ticket and how long an automated service status waits for settlement confirmation. Convenience at normal volume is less important than deterministic behaviour around an exception.

Regulation travels through the same record

For a Brazilian ISP, customer data is not just an operational memory. It is evidence for billing, taxation, consumer rights, sector reporting, and confidentiality obligations. Anatel’s2025 guide for small telecommunications providerssummarises obligations including service data submissions, infrastructure and economic reporting, billing information, and cybersecurity measures. The regulator’s economic portal now publishesquarterly provider indicators. An integrated ERP can help produce consistent totals, but it cannot decide the legal scope or certify the accuracy of what the operator has entered.

Consumer flows are equally concrete. Anatel states that a subscriber canrequest cancellation through available service channels, subject to applicable rules and remaining legitimate obligations. Invoices, duplicatas, service statuses, protocols, and cancellation timestamps must align. Automation that improves collection but masks a cancellation request would be operationally effective and legally dangerous. Buyers should trace each regulated journey, from customer request to final invoice, through network action, protocol, and retained evidence.

Privacy roles change by context. MK’s policy states that MK Solutions Criação de Software Ltda acts as a controller for information it collects for its own purposes and as a processor when handling data provided by customers through support and software use. The policy identifies names, CPF numbers, addresses, contact details, usage statistics and records, and mentions external hosting or service partners and possible processing outside Brazil. The separateMK SAC privacy noticediscusses a broad mobile app data set, including biometric selfie data in a consent context. These notices support diligence; they are not a complete data processing agreement or subcontractor register.

Brazil’sLGPDrequires security measures and governs controller and processor responsibilities. TheANPD incident guidelinesstate that a controller must communicate a confirmed incident likely to create relevant risk or harm to the authority and data subjects within three business days. Anatel’s guide adds sector expectations and reporting interactions. Contractual language should therefore allocate detection, evidence preservation, notification inputs, decision authority, and available hours—not just promise that parties “will comply with the LGPD.”

The public privacy page itself deserves governance scrutiny. It contains an apparent editorial note in the live text and broad descriptions of international processing and security. This does not show unlawful processing or technical failure. It shows why the buyer should ask for the dated and approved notice, the data processing agreement, the subcontractor list, the retention schedule, the transfer mechanism, and deletion evidence rather than treating a web page as the entire control framework.

Privilege concentrates where the work is done

The most consequential security surface is not a login page; it is the permission to modify a customer’s operational state. Agentes+ can expose subscriber information, access credentials, and equipment identifiers to field users and can support provisioning. CRM+ can collect identity documents, photos, and precise location. API profiles can reach contracts, invoices, and service orders. Maps can modify topology and capacity records. Payment connectors carry banking credentials and certificates. A compromise or overly broad role in any of these areas can spread further because the suite is integrated.

MK indicates it uses access restrictions, contractual obligations, firewalls, encryption, certificates, and anti-attack measures. TheMK SAC listingon Google Play identifies MK Solutions Criação de Software Ltda as the developer and displays developer declarations about data collected, encryption in transit, and sharing. These are useful representations, not independent penetration tests or certification reports. The reviewed public documents did not provide a current ISO 27001 certificate, SOC report, penetration test summary, vulnerability disclosure programme, subcontractor inventory, or detailed security white paper linked to the assigned CNPJ.

Backup claims also require separation from assurance. MK markets amirror database serviceas a real-time replica and describes an ISP that allegedly discovered failing FTP backups after hardware issues. The story is written by the provider, the customer is not independently substantiated on the page, and “real-time” is not a measured recovery point objective. Replication can faithfully copy corruption or unauthorised modification; it is not a substitute for isolated, tested backups. A procurement test should delete or corrupt selected records in a non-production environment, fail the primary host, restore to a chosen point, and reconcile transactions generated during recovery.

Public complaint data provides a weak but relevant external signal. MK Solutions’Reclame Aqui profileshowed only 11 complaints in the June 2025–May 2026 window at the time of review, including user allegations about tax documents and API instability. The platform reported responses to all complaints and a small evaluated sample. This is self-selected, unaudited, and too sparse to estimate incident rates. It proves neither a systemic failure nor validates reliability. Its value is to suggest scenarios a buyer can ask reference customers and support managers to prove.

No credible public disclosure of a material MK breach or specific product public vulnerability was identified in the frozen evidence set. This is not proof that none occurred. Private B2B incidents, remediated findings, and component vulnerabilities may never appear under the brand name. The correct due diligence request is an incident history, vulnerability management policy, dependency inventory, patch metrics, authentication controls, privileged session logging, and recent independent test results—with scope, dates, and exceptions visible.

Customer evidence remains thinner than product evidence

MK publishes extensive product details and a set of success testimonials. This asymmetry is itself informative. Public documentation allows understanding of many workflows, while outcome evidence is largely provider-selected. The case study page cites attractive returns and savings without the full contracts, starting costs, sample periods, or independent calculations needed to reproduce them. ClienteSA provides one named customer voice and internal service statistics, but not a representative cohort.

This does not mean the results are false. Vertical enterprise software is often difficult to evaluate publicly because customer configurations and commercial terms are confidential. It means a buyer should not translate “2,500 active customers” into 2,500 equivalent production deployments, or assume that a number of connections means every subscriber uses every module. Ask how “active,” “customer,” and “connected” are defined; whether reseller, test, acquired, and partial-module accounts are included; and how many customers match the buyer’s connection volume and deployment model.

References should be chosen by operational resemblance, not logo prestige. A multi-CNPJ group should speak with another consolidator. A rural wireless and fibre provider should find a mixed-network reference. A buyer dependent on a specific bank, OLT family, tax municipality, or WhatsApp provider needs that exact combination. Conversations should occur without the vendor present and cover failed migrations, month-end, upgrades, incident communication, ticket escalation, and data extraction alongside successful go-lives.

There are also honest evidence gaps that reference calls cannot fill. Public sources do not disclose customer concentration, churn, module adoption, infrastructure availability, severity-one ticket volume, development headcount, current total employee count, or independently audited current connection numbers. Procurement should record these as unresolved if MK declines to provide them. An unknown is safer than a confident number built from marketing fragments.

Rivals compete for the same centre of gravity

MK is not alone in trying to become the operational centre of a Brazilian ISP.SGPmarkets an integrated provider system covering subscribers, finance, tax work, inventory, network and FTTH functions, applications, support, migration, and hundreds of integrations.IXC Provedorpresents an ISP ERP with implementation, training, network, and customer operations.HubSoftexposes documented APIs around its own provider platform. Other vertical suites and specialised OSS/BSS products broaden the field.

Feature table parity is therefore easy to overestimate. Many providers can list CRM, billing, Pix, field service, inventory, dashboards, and support. The significant differences are depth and failure behaviour: which OLT and bank versions currently work; how tax rules are maintained; how a mass change is audited; how quickly a migration exception reaches an expert; how a payment reminder is replayed; how topology and stock are reconciled; and how well a customer can export data.

The primary substitute is not always another suite. A larger ISP may combine a general CRM, billing engine, network inventory, RADIUS or AAA platform, workforce management tool, data warehouse, payment orchestrator, and integration layer. This composite approach can reduce dependency on a single vendor and allow each domain to evolve independently. It also creates interfaces to build, monitor, and support. A small regional provider may rightly prefer MK’s vertical defaults over becoming its own systems integrator.

The decision is therefore not “integrated good, modular bad.” It is about where the operator wants complexity to reside. MK internalises much of the coordination into a product and support relationship. A composite estate internalises it into architecture, engineering, and vendor management capability. The correct comparison prices both the software and the organisational burden, then tests which failure modes the ISP can actually handle.

Leaving is a continuity project

Switching costs begin well before contract termination. Staff learn MK’s states and shortcuts. Bots and customer portals depend on its endpoints. Payment profiles, banking credentials, OLT scripts, tax settings, roles, reports, and field routines accumulate around the platform. Historical tickets and topology changes become evidence. Management dashboards acquire definitions that may not map cleanly to another ERP. None of this is abusive dependency per se; much of it is the accumulated value the customer asked the suite to create.

The risk emerges when the accumulated value cannot be represented elsewhere. MK’sgrids documentationdescribes export to formats including CSV, XLSX, and PDF. This is useful for selected views, but is not evidence of a complete, relational, documented export of customers, contracts, invoices, payments, tax events, network topology, inventory custody, service orders, audit history, attachments, and integration configuration. API access is not automatically a exit interface either: it may omit history, impose limits, or require the production system to remain licensed.

A credible exit test should happen before signing. MK should provide a data dictionary, entity relationships, attachment format, time representation, character encoding, stable identifiers, deletion markers, and volume limits. The buyer should export a representative environment, load it into neutral storage, and reconstruct several histories without looking at the MK screen. It should verify totals and relationships, not just open files. The contract should specify extraction assistance, fees, timeline, read-only access, post-termination retention, secure deletion, credential revocation, and cooperation with the successor.

Operational cutover is harder than extraction. During a change, invoices still come due, Pix payments arrive, technicians install service, customers request cancellation, and regulators may ask for evidence. A provider needs a freeze policy, discrepancy capture, interface transition, rollback threshold, and a historical read-only access period. It must decide which platform can modify each record at each step. A “big bang” that leaves both systems accepting payments or network actions can be worse than a delayed migration.

Exit planning also improves the current deployment. To prove portability, the ISP must know its own canonical identifiers, data owners, retention rules, and dependencies. These disciplines reduce migration risk, improve audits, and expose undocumented customisations. A provider confident in its daily value should be able to support this clarity; the product should be retained because it works, not because the customer cannot rebuild.

The procurement room should run the operation

A responsible evaluation should replace the module tour with a controlled operational rehearsal. The following tests are designed around MK’s actual proposition rather than a generic ERP evaluation.

First, settle identity and scope.Obtain current registry evidence for CNPJ 09.587.408/0001-86 and the successor company MK Solutions Tecnologia S.A.; map the 2025 incorporation steps; identify the contracting, billing, hosting, intellectual property, and data processing entities; ask for the status and consequences of the proposed Nuvini transaction. Make change-of-control, assignment, and continuity clauses explicit.

Second, build a hard subscriber journey.Use synthetic data to create a lead with two addresses, test FTTH feasibility near a capacity limit, sign a plan with a discount, allocate and provision an ONU, issue a tax document and a Pix charge, skip the payment reminder, open a complaint, replace equipment, change plan, and request cancellation. Inspect each resulting state, timestamp, permission check, notification, accounting entry, and audit record. Repeat a step offline via the field app and one via an API partner.

Third, rehearse migration rather than discuss it.Provide a representative extract with duplicates, malformed CPFs, credits, instalments, inactive plans, reused equipment, missing contact details, and contested balances. Require a mapping report, exception queue, and state-by-state reconciliations. Run billing, tax, banking, and authentication results in parallel. Ask which transformations are reproducible and which rely on manual judgment.

Fourth, break dependencies deliberately.Expire a banking certificate, withhold a webhook, duplicate a Pix notification, make an OLT unreachable, reject a municipal tax document, break DNS, remove mobile connectivity, and defer an ERP update. Observe retries, queues, alerts, manual overrides, and reconciliation. Confirm that a failed financial integration does not silently trigger the wrong service action.

Fifth, inspect privileges.Examine role models for sales, finance, support, network, warehouse, field contractor, and administrator. Test multi-factor authentication, session revocation, API token scope and rotation, bulk export approval, segregation of duties, and audit retention. Ask for independent penetration test results, remediation evidence, subcontractor and hosting details, backup isolation, and a timed recovery exercise.

Sixth, measure support with evidence.Obtain severity definitions, response and restoration histories, escalation flowcharts, staffing coverage, maintenance communication, status mechanisms, and named references. Open test tickets that cross finance, network, and tax domains. Determine who owns a problem spanning MK, a bank, an OLT vendor, and a messaging partner.

Seventh, price the actual five years.Include every module, environment, migration wave, training hour, API, message, payment service, infrastructure level, acquisition, data growth, tax change, upgrade, and extraction. Apply connection growth and decline. Separate contractual price protection from vendor expectation.

Finally, leave before buying.Export the synthetic deployment, rebuild subscriber and network history in neutral storage, rotate or revoke every credential, and restore from backup. Put delivery timeline, completeness criteria, and assistance in the contract. If exit cannot be demonstrated with a small environment, it will not become easier after five years of operational history.

What is worth watching now

The first watchpoint is corporate identity. The original CNPJ remains the verified boundary for this research, while public notices point to incorporation into a successor company. Customers should monitor registry status, contract assignments, and the contested and still-conditional Nuvini transaction rather than inferring finalisation from branding.

The second is evidence maturity. MK publishes unusually useful workflow documentation, but its current scale, performance results, service levels, and security posture are less independently visible. A dated architecture and security pack, a stable status history, a transparent integration catalogue, and consistently defined customer metrics would significantly improve external confidence.

The third is product expansion. Each additional payment, bot, mobile, analytics, or partner function increases the continuity value and the number of dependencies that must be governed. Buyers should track whether identity, permissions, audit, version management, and export coverage remain consistent across modules rather than assuming the ERP core automatically controls new surfaces.

The fourth is regulatory and market economic pressure. Anatel is tightening reporting and cybersecurity requirements while describing consolidation among fixed broadband providers. Banking APIs and tax interfaces continue to change. A vertical provider can turn these changes into shared leverage for thousands of customers—or a shared bottleneck if updates, support, or data quality fail.

A control plane earns its place every day

MK Solutions’ most credible advantage is not having assembled a long feature list. It is that the list follows the real life of a broadband subscriber. The same commercial promise can reach a fibre capacity decision, a technician, an invoice, a payment, a support protocol, and a management report. In a fragmented Brazilian market, this operational continuity can give a regional ISP capabilities it would struggle to design alone.

But continuity is also concentration. The data model becomes an operational language. Support becomes part of incident response. Banking and equipment interfaces become production dependencies. A legal reorganisation can count as a service desk. An export clause can become a business continuity control. Marketing claims about scale or savings are least convincing precisely where the product is most consequential.

The correct conclusion is neither automatic endorsement nor fear of dependency. It is a higher evidence standard. MK should be judged on exception handling, migration reconciliation, privileges, recovery, regulatory evidence, and exit—not just on a clean demo’s ability to turn a lead into an invoice. The bill can touch the broadband because the platform joins the operation. That power is valuable when the ISP can see, test, and ultimately control every link in the chain.