Buy two SaaS assets as a separately agreed portfolio

To buy a SaaS portfolio through Codeblix, request the separate existing software assets and agree each purchase individually. ThatQuis and Macro-Manage are concrete candidates in this worked case. They are not advertised here as a pre-existing bundle, a merged company or a shared application. Each has its own current listing, product promise, source package and transfer conversation.

The buyer in this example wants to own two independently operated products. One helps creators build quiz journeys and capture consented leads; the other helps organisations maintain member rosters and fee records. A portfolio decision concerns which commitments the buyer can hold together, which must remain separate, and whether a second acquisition should proceed after the first. It is different from choosing one product from a list of business ideas.

Open two individual offers instead of assuming a portfolio package

Request the individual ThatQuis acquisition offer → Request the individual Macro-Manage acquisition offer →

Check availability, price, represented financial history and included assets through each current Flippa transaction. The ThatQuis marketplace page and Macro-Manage marketplace page connect the separate products with their previews and documents. Request an acquisition schedule that names both offers only if the seller confirms both remain available and is willing to discuss that arrangement.

There is no combined price, discount, customer list or transfer package implied by this article. A seller agreement for one asset does not reserve the other. Likewise, acquiring both does not deliver cross-product billing, shared customer identity, consolidated administration or an integration between them. If the buyer needs any of those things, they belong in an additional agreed scope.

The example buyer wants two businesses with two understandable promises

Imagine an adult operator with a named technical maintainer and a named customer-service owner. The operator is considering ThatQuis first and Macro-Manage second. This is a fictional purchase scenario, not a representation that an existing buyer, workforce or trading company is included in the offers. The operator's reason for investigating the pair is an interest in focused software products with different customer jobs.

ThatQuis customers create and publish question-to-result experiences. Its documented foundation includes branching, scoring, outcomes, versioned quizzes, respondent progress, workspaces, usage controls and software plans. Macro-Manage customers keep organisation rosters, a twelve-month fee grid, full and partial payment records, histories, receipts and exports. The fee records concern what an organisation has entered; they do not make the platform the custodian of member payments.

The buyer should be able to explain both promises without saying that one is simply another feature of the other. A quiz creator expects their published journey and responses to behave consistently. A fee administrator expects the correct organisation, person and period to be visible in records. Owning two products means accepting both customer expectations, even if the underlying applications share several technologies.

Define the portfolio by ownership rather than a combined interface

A portfolio can consist of separately owned and operated assets. It does not require one dashboard or one public brand. For this purchase case, the portfolio record names each domain, repository, application, service arrangement and responsible operator. Keeping those boundaries explicit lets the buyer consider two purchases without inventing an integrated product.

Write the intended customer-facing position of each asset. The buyer might retain the existing individual identities while separately reviewing their future marketing. It should not promise that ThatQuis users will automatically become Macro-Manage customers, or that either application's demonstration accounts can be used as a sales audience. A shared owner does not establish permission to combine records or send a different product offer to someone.

This distinction also protects the purchase sequence. The buyer can accept one product under its own agreement while the other remains under discussion. A portfolio goal does not turn an unfinished second transfer into a completed acquisition. Keep the status of each offer visible so that “we are buying two” never becomes a substitute for the actual accepted package.

Use a two-asset offer schedule with an independent decision in every row

Include an owner and an expected evidence location for each row. The seller's answers for ThatQuis should not be copied into the Macro-Manage row just because both are offered by Codeblix. The exact repository state, accounts, application settings and transfer tasks may differ. The schedule should make those differences easier to discuss, rather than disguise them beneath a portfolio label.

Give each row a genuine hold option. A buyer might be ready to acquire ThatQuis while still resolving a Macro-Manage requirement, or the reverse. Confirm the actual transaction terms with the seller instead of assuming one completion depends on the other. This article does not create a combined reservation, an automatic cancellation right or a cross-asset payment arrangement.

Choose the first closing by its accepted operation

The first acquisition should establish an operating baseline the buyer can actually maintain. It need not be the application with the longest feature list. Ask which product has a clear initial customer promise, a named technical owner and a purchase test your team can explain. Then agree its individual transaction and transfer requirements.

For the worked buyer, the first candidate is ThatQuis. The buyer brings an artificial question route, an expected result and a consent decision. It uses that small example to inspect the current application and agree the delivered baseline. The detailed ThatQuis purchase brief remains the authority for that individual product inspection; the portfolio record only tracks whether the buyer has accepted and can operate it.

After the transfer, the buyer should be able to identify who responds to a creator problem and who maintains the application. That is the operational fact relevant to a second purchase. A completed repository transfer alone does not show the buyer has room to support another product. The portfolio schedule should distinguish an acquired asset from an asset whose ordinary operating responsibilities have found an owner.

Make the second offer conditional on real capacity, not a hopeful timetable

A second product introduces another customer promise even if the team can reuse some knowledge. The buyer should review the first product's actual open work before accepting a second transfer date. This does not require a fabricated staffing forecast. It requires a named person to say which responsibilities they will take and which remain unassigned.

In the worked case, Macro-Manage introduces organisation fee records and roster administration. A support question may concern an imported name, a year selection or a payment entry that differs from an organisation's external receipt. That is different from explaining a quiz branch to a creator. The same support person may handle both, but they need the correct product context and escalation route.

If the person who maintains ThatQuis is also expected to accept Macro-Manage, give them authority to hold the second schedule until they can inspect it properly. Do not describe that hold as a product defect or a seller obligation to wait indefinitely. It is a buyer capacity decision to negotiate through the actual offers. No suggested calendar in this article overrides those terms.

A shared stack is knowledge reuse, not a shared production account

Both applications use a React and TypeScript frontend with a Convex backend, Clerk authentication and Stripe software billing foundations. An engineering team familiar with those components may find the common vocabulary useful during inspection. That does not establish that the applications share the same configuration, data model, release process or service accounts.

The portfolio record should show what is owned, what is transferable and what the buyer must establish for each product. A public browser setting is different from a private backend credential. A service dashboard that can display several applications is different from one unrestricted account serving every customer. Use the actual transfer plan to determine the arrangement rather than copying a secret or configuration from one product into the other.

If the buyer later wants common administration, it should specify that as a new project. The existing source packages do not promise automatic consolidation. Likewise, a change to a shared provider account should not be described as harmless to the other asset without checking the actual arrangement. The portfolio owner needs visibility of common dependencies while preserving each application's accepted operation.

Keep the customer's subscription tied to the product they purchased

ThatQuis creators and Macro-Manage organisations have different product entitlements. Owning both applications does not give either customer automatic access to the other. If the buyer retains the individual product offers, it should be clear which account, plan and support promise belongs to each application.

For a purchase workshop, describe one fictional creator and one fictional organisation. The creator has a selected quiz plan. The organisation has a selected fee-software plan. Ask the seller to show how each application's existing access is represented, then record the future buyer-owned arrangement. Do not use a demonstration plan label as evidence of an actual paid subscription or live renewal.

A combined subscription could be a later commercial idea, but it is not delivered by acquiring both repositories. It would require defined entitlements, customer communication, billing and support behaviour, with the appropriate rights and implementation. Keep it outside the portfolio acquisition unless it is explicitly agreed. This lets the buyer make a current purchase without silently selling a new bundle to future customers.

One support inbox still needs two separate operating records

A buyer may choose a single public support contact for both products. That is a future operating choice, not a feature included by the portfolio transaction. If it is chosen, the staff procedure should identify the product before asking a customer to provide information or attempting to reproduce a problem.

For the fictional buyer, a ThatQuis creator reports that a published answer path produced an unexpected result. The support record needs the relevant quiz and version context. A Macro-Manage organisation reports a partial payment entered in the wrong period. That support record concerns the permitted organisation, member and fee period. The product names are not enough; the operator needs the correct object and authority for the requested action.

Keep customer material inside the agreed product support boundary. The fact that one owner operates both apps is not a reason to place a school's roster inside a quiz support workspace. Use permitted artificial examples for cross-product staff training. Any new shared support system should be chosen and configured by the buyer as its own operating project rather than represented as an inherited portfolio asset.

Distinguish each revenue model from the absence of represented earnings

The relevant product model in both cases is software access: creators subscribe to a quiz application and organisations subscribe to a fee-record application. The intended model tells a buyer what it plans to sell. It does not prove that a paying customer base, income stream or successful renewal history is included.

Use each current sale's financial representation and supporting evidence. Demonstration responses, sample members and test plan assignments are product examples. They are not portfolio revenue. Adding two sample counts together does not create commercial traction, and a second domain does not automatically reduce the buyer's operating risk.

The buyer should also avoid moving an imagined future benefit into the current offer. It might hope to reach quiz creators through one channel and schools through another, but neither audience is transferred unless explicitly evidenced and included. The acquisition schedule should state what the buyer receives now. Its own channel, staffing and product development plans remain future commitments under its control.

Separate feature maintenance from portfolio administration

Product maintenance concerns a specific application's customer behaviour: a question route, a result export, a roster import or a fee-history view. Portfolio administration concerns ownership and operating commitments across both: who controls the domain, which person receives an account notice and which individual sale has an unresolved transfer item.

Give those two categories separate places in the buyer's record. A general task called “finish the portfolio” can hide an unfinished application issue. A list of product features can hide the fact that no one owns a domain renewal or a service-provider account. The acquisition schedule is useful because it exposes both categories without pretending they are one interface.

For a shared maintainer, write the escalation rule when both products have open work. The rule need not promise a response time the buyer cannot provide. It should identify who makes the decision, who informs the affected product's customers and where the actual work is tracked. This is an operating commitment to establish, not proof that either product requires unattended intervention.

Keep two transfer finish points visible after the purchase

Confirm the assistance offered for each individual asset and its agreed duration or finish point. Do not assume the second acquisition restarts assistance for the first, or that portfolio ownership creates indefinite development support. If the buyer requests work across both applications, ask for that scope separately.

The first transfer might leave the buyer with an accepted source baseline, controlled services and completed product walkthrough while the second still awaits a service-account action. Record that actual state. A combined announcement or a single invoice, if separately agreed, would not replace evidence that each application was delivered according to its own transaction.

Read the Macro-Manage individual purchase ledger for its roster, partial-payment, permission and import acceptance work. Keep those checks attached to the Macro-Manage record. The portfolio page should help the buyer coordinate two decisions, rather than weaken the detailed product tests into a generic tick beside each domain.

Rehearse a week in which both customer promises need attention

Use a small fictional operating week before accepting the second asset. A ThatQuis creator needs help understanding a changed result path on the same day a Macro-Manage administrator asks about a fee entry. Later, the technical maintainer needs to review one product change while the owner receives an account notice for the other. These are illustrative responsibilities, not a claim about current customers or the frequency of support requests.

Ask the named owners to route each item to the appropriate product and person. Do they know which application baseline is in use, where the authorised record belongs and who can act? If one person is unavailable, does another person understand the scope they may handle? Keep this rehearsal focused on the buyer's actual proposed staffing, without inventing a support organisation sold with the assets.

The purpose is to produce an explicit second-purchase decision. If responsibilities remain unassigned, hold that offer discussion or revise the buyer's operating plan. If the team can explain the work and accept the commitments, it has a stronger basis to request the second transaction. The example is a decision aid, not a promise of a particular workload, cost saving or return.

Record what a hold on one offer means for the other

A portfolio proposal is more credible when it explains the buyer's decision if only one acquisition can proceed. Suppose the buyer accepts ThatQuis but has not resolved who will maintain Macro-Manage. The second row should remain a live discussion with its own status. It should not be described to staff or customers as a completed acquisition merely because the owner originally intended to buy two products.

Ask the seller to identify any actual dependency between the proposed transactions. If the offers remain independent, record that answer alongside their separate terms. If the parties negotiate a different arrangement, use the written agreement to explain it. This page does not establish a right to reserve the second asset, change the price of the first or undo an accepted purchase. The buyer needs a real answer for the particular transaction it is considering.

Apply the same discipline to operating decisions. Holding a new Macro-Manage offer should not cause the buyer to suspend an already accepted ThatQuis customer promise. The owner should know which services and responsibilities belong to the first asset and which would begin only after the second transfer. That distinction is one of the practical reasons to keep the asset and dependency records separate from the beginning.

Do not turn a possible future combined brand into a condition that prevents either individual product from being understood. The buyer can revisit its portfolio presentation after accepting the applications. At purchase, each offer should stand on a named package, an observable operation and a responsible person. A portfolio is easier to manage when the owner can explain both the two-asset plan and the honest one-asset result.

Complete a purchase record that can hold either asset independently

Use the checklist to prepare a two-asset conversation. A checked item records an answer the buyer has obtained; it does not reserve an asset or accept terms on the buyer's behalf. Keep the underlying individual transaction documents and evidence with the corresponding product record.

Both current individual offers are identified and their availability has been confirmed.Each application has its own agreed source, domain, documentation and transfer scope.The buyer can explain each separate customer promise without assuming a bundled product.Service ownership and any actual common dependencies are recorded for each asset.Technical maintenance and customer support have named owners for both products.The second acquisition has a proceed or hold decision based on its own evidence and real capacity.Any proposed shared billing, accounts or integration is excluded unless separately agreed.The assistance and finish point of each individual transfer are clear.

0 complete

Reset portfolio record

1. Request the current package for each asset through its own listing.
2. Complete two offer rows with separate evidence, terms and responsible people.
3. Agree the first transfer without representing the second as already acquired.
4. Review actual operating capacity before proceeding with the second individual purchase.
5. Keep any future combined product project outside both acquisitions until expressly agreed.

Contact Codeblix through ThatQuis and Macro-Manage to discuss the two existing asset offers. A credible portfolio proposal names what the buyer wants to acquire, what stays independent and who will operate each product. It does not need to promise a combined suite in order to make two concrete acquisition requests.