Provision buyer-approved services, restore synthetic or authorized data, and document recovery behavior with an independent clean deployment.
Asset overview · IES-1.0A useful layer
before the loan.
Mortgage resources built for the daily work around a loan. An evidence-led view of what exists, what remains outside scope, and what a buyer would need to verify.
PERIMETER · Studio 1003 public website, market intelligence, mortgage tools, and publishing software. Excludes the separately hosted CRM/POS application and this investor experience.
01 / The context
Mortgage work lives between systems.
A borrower conversation moves through affordability, product context, rate changes and documentation. Useful information is often scattered across sources and tools.
A
Context changes at different speedsWeekly survey benchmarks, daily indicators, and borrower assumptions are not interchangeable.
B
Information needs an explanationCalculations help structure a conversation. They do not replace lender policy or underwriting.
C
Workflow is a separate product questionPublic resources are implemented here. The separately hosted CRM/POS is outside this audited perimeter.
Market context, not market sizingCFPB HMDA data describes lending patterns. It is not a count of likely customers or software spend.
A resource layer that works before signup.
Explore the actual Studio 1003 tools below. These routes open the public application, without requiring a CRM account. They are Development verified, not Production certification.
Authentic Development capture
Mortgage payment
Mortgage payment
Development verified
Mortgage payment
Turn a purchase scenario into a clear payment discussion.
Change the price, down payment, loan type, term, or rate in the real calculator.
Inspect principal and interest alongside configurable ownership-cost estimates. These are estimates, not credit decisions.
Open live public tool
Authentic Development capture
Rates and indicators
Rates and indicators
Development verified
Rates and indicators
Separate national mortgage benchmarks from daily market indicators.
Switch observation windows and inspect published dates, series sources, and history.
A source-linked market reference without presenting a Treasury yield or survey average as a borrower quote.
Open live public tool
Authentic Development capture
Income qualification
Income qualification
Development verified
Income qualification
Make income assumptions and document requirements visible.
Select income types, enter synthetic figures, and inspect the calculation worksheet.
Transparent qualifying-income estimates and document checklists. Lender review and underwriting remain separate.
Open live public tool01 / CALCULATE
Make assumptions visible
Mortgage scenarios with adjustable inputs and explainable estimates.
02 / ATTRIBUTE
Keep context attached
Rates and market references show dates, sources, and observation windows.
03 / PUBLISH
Support the resource lifecycle
Editorial and newsletter workflows are fixture-tested; Development checks do not establish live delivery.
Buy what fits. Build what is missing.
The public repository is an assembled implementation, not an assertion of feature parity or universal advantage. Compare choices through a specific buyer’s requirements.
Acquire / adapt
Start from the assembled resource layer
Potentially useful when these components fit an existing distribution strategy and can legally transfer.
- Mortgage calculation modules
- Source-aware public information
- Editorial and publishing workflows
- Requires rights, setup, security and adaptation diligence
Build / license
Choose an alternative service or implementation
Reasonable when a buyer needs a narrower capability, a supported vendor relationship, or a different workflow.
- Build a tailored resource experience
- Use agency data and existing calculators
- Evaluate a mortgage CRM or POS category service
- No vendor integration, price or parity comparison is asserted
Evidence to request
Test fit before estimating savings
Use a buyer-specific checklist, not a generic feature grid.
- Which workflows are required on day one?
- Which code and rights can actually transfer?
- What independent security and recovery work is needed?
- What adoption evidence would change the decision?
Alternatives named in evidence
Category references only
Shape is a mortgage CRM reference; Floify is a mortgage POS reference. No feature parity, price, performance, or compatibility is claimed.
- Provider terms can change
- Validate buyer requirements directly
- Obtain current demonstrations and vendor terms
- Consider using an existing service instead of acquiring software
The software is inspectable. Traction is not verified.
Engineering evidence and commercial evidence answer different questions. No CRM interface or numeric performance story is fabricated here.
Verified in this scopePublic resource software
Selected routes, tests, build, type checks, and Development browser behavior support a limited implementation claim.
Not suppliedNo verified revenue or users
No reconciled contracts, invoices, paid cohort, retention series, traffic series, or customer proof is available to this assessment.
Outside perimeterCRM/POS not audited
The authenticated, separately hosted CRM/POS runtime is excluded. Public subscription messaging is not evidence of subscriptions.
05 / Business model
Subscription positioning is not revenue.
The broader product is positioned around subscription access for individuals and teams, with enterprise discussions handled separately. This assessment does not verify that model in operation.
01
Workflow productCRM/POS subscription is the stated positioning, subject to verification of the separate application.
02
Resource distributionOpen tools may support education alongside a paid product. That conversion path is a hypothesis.
03
Operating economicsHosting, data, email, content review and maintenance costs require actual invoices and usage evidence.
No public number before owner approval.
The private replacement-cost analysis is not reproduced here. The public control uses neutral effort units only, so visitors can inspect the logic without seeing a financial estimate.
Public scenario explorer
Effort sensitivity, not a price
Explore how a hypothetical reusable share compares with buyer-side work. Neutral effort units have no currency conversion and do not disclose the private model.
Checking publication status…Public snapshot: Under review.
Reusable effort100
Buyer effort0
Conditional sensitivity100
Illustrative scenario only. The calculation is not price, fair market value, a bid, an offer, an appraisal, or a guarantee of savings. No demand, transferable rights, market comparables, or customer economics are assumed.
Ranges shown as low · central · high.
Approved acquisition sensitivities
These are approved scenario estimates, not an appraisal, price, bid, offer, or guarantee of realizable proceeds.
A score is a diligence map, not a verdict.
Based on the dated assessment and its stated scope. Open any line to inspect supporting evidence and the next verification priority.
Overall acquisition readiness38 / 100
Technical & operational38 / 65
Excludes ownership and commercial validation.
Ownership & transfer0 / 20
Commercial evidence0 / 15
Readiness rubric · 2026-10-17 · Technical and commercial dimensions kept separate.
Working functionalityVerified · 12/20
Calculators and public routes are testable here. Publishing transports are fixture-tested. The CRM/POS runtime is outside this repository.
Priority: Obtain authorized end-to-end evidence from the separate product.Architecture and testsVerified · 11/15
Shared calculation modules, typed routes, automated regression tests, build and type checks. Coverage is focused, not exhaustive.
Priority: Add independently reviewed integration and recovery tests.Security and privacyVerified · 8/15
Server-side challenge verification, input validation, secure headers, and Development side-effect guards. No independent penetration-test certification.
Priority: Complete an authorized security and retention review before release.Ownership and transferNot yet verified · 0/20
Contributor assignments, brand/domain ownership, data licenses, and transferable service agreements have not been supplied.
Priority: Assemble the IP and licensing schedule with counsel.Operational independenceVerified · 4/10
Standalone deployment configuration and operating notes exist. A clean-room transfer and restore exercise has not been demonstrated.
Priority: Prove backup, restore, service provisioning, and domain transfer.Product usabilityVerified · 3/5
Responsive public resources and accessible controls are implemented. No independent user study establishes workflow efficiency.
Priority: Run task-based usability sessions with mortgage professionals.Commercial validationNot yet verified · 0/15
No verified customer cohort, paid contracts, recurring revenue, acquisition interest, or product-market fit is available to this assessment.
Priority: Provide permissioned analytics and reconciled commercial records.Evidence before expansion.
Filter the diligence track. These are priorities, not committed dates or capabilities already included in the asset estimate.
Obtain authorized evidence for intake, role boundaries, persistence, pipeline ownership, LOS handoff and failure recovery in the separate application.
Agree privacy, support and measurable success criteria before testing repeat use, willingness to pay, and support burden.
The full evidence, in one place.
Fourteen crawlable chapters, published from the shared assessment source. The PDF endpoint is provided separately and should match this document version.
IES-1.0 · Assessment dated 2026-10-17 · 14 chapters
Download PDFExecutive summary
An implemented public resource layer. A broader product thesis still to verify.
Studio 1003 is positioned as a mortgage CRM and borrower point-of-sale workflow layer for loan officers and teams. Its intended role is to organize the relationship and intake work before the loan origination system. It is not represented here as an LOS replacement. The repository assessed for this memorandum is the public website and market-intelligence application, not the separately hosted, authenticated CRM/POS product.
The verified asset includes interactive mortgage tools, dated rate observations, source-linked market resources, and software for editorial and newsletter workflows. The acquisition case for this perimeter is a reusable public-resource foundation that a mortgage business could adapt to its own distribution. It is not a claim to a revenue-producing operating company or a proven customer-acquisition engine.
Commercial traction, ownership assignments, recurring operating costs, and transfer permissions require evidence. Public financial estimates are withheld until explicit owner approval. The private replacement-cost analysis excludes the investor experience itself and does not use assumed recurring revenue. A prospective buyer should begin with the working resources, then establish which assets and rights can actually transfer.
Industry problem
Mortgage context is fragmented. Better information does not replace the lending stack.
A mortgage conversation combines borrower circumstances, affordability, product constraints, market changes, documentation, and institutional policy. The information comes from different systems and changes at different speeds. A public reference layer can reduce the effort of locating calculations and sources, while a CRM/POS workflow may help organize borrower follow-up. These are related but distinct product responsibilities.
CFPB HMDA data provides evidence of mortgage activity and lending patterns. It is not a count of people willing to buy Studio 1003 or a proxy for software revenue. This memorandum does not convert loan volumes into a total addressable market. Establishing a commercial opportunity requires identifying actual purchasing teams, their current tools, their budgets, and the cost of reaching them.
Rate information also needs context. Freddie Mac publishes national weekly mortgage survey results, while Treasury and overnight financing series have different frequencies and meanings. A useful resource must show observation dates and distinguish a national benchmark from a personalized offer. Studio 1003 implements those distinctions in its public rate interface; no reduction in closing time or improvement in pull-through has been measured.
Product vision and existing solution
CRM/POS-first positioning, supported by open mortgage resources.
The intended product serves individual mortgage loan originators and teams that need borrower context, clear ownership, organized intake, and an orderly handoff to the LOS. The public website explains this workflow and links to a separate request-access application. Those marketing descriptions are not sufficient evidence that every authenticated workflow is operational, transferable, or available under a particular subscription.
Within this repository, the public experience is useful without an account. Visitors can explore mortgage tools, published rate history, market-news sources, educational material, and product information. Keeping these resources open is a product decision rather than an assumption that free usage becomes paid demand. No CRM signup is required to read this memorandum or use the demonstrated tools.
The investor experience therefore separates the product vision from the audited asset. Demonstrations open real public pages and use genuine interface captures. Any future verification of the CRM/POS application should include authorized synthetic borrowers, role-specific access, intake completion, persistence, handoff behavior, and failure recovery. Until that evidence exists, the separate application remains outside the current software estimate.
Product functionality and maturity
A capability earns its label through behavior, not its appearance.
The public toolset includes purchase, refinance, income, payment, and guideline-oriented workflows. Shared calculation modules implement amortization, remaining balance, extra-payment effects, and other mortgage-specific logic. Calculator results are scenarios. Taxes, insurance, program eligibility, underwriting treatment, and lender overlays require their own review. Historical limits or guidelines must be checked against the period and source displayed by the tool.
The rate layer retrieves source observations, preserves dates, and supports history windows. Market and economic-release modules use source attribution, freshness handling, and separate event status. Tests exercise observation integrity and display transformations. These controls help avoid unsupported summaries, but they do not guarantee that every third-party source is current, complete, or available at every moment.
Newsletter and editorial code includes content generation, rendering, confirmation and unsubscribe paths, delivery integrations, and scheduled jobs. Development tests mock external transports and suppress live delivery and publishing. That provides evidence of controlled software behavior, not fresh proof of Production delivery. Evidence labels distinguish proposed work, interface prototypes, partial implementation, Development verification, and authorized Production verification.
Market opportunity
Start with a specific buyer and a measurable use case.
Potential users include loan officers seeking a daily market reference, teams explaining payment tradeoffs to borrowers, and mortgage businesses maintaining educational resources. These segments have different needs and buying authority. A free calculator visit is not equivalent to a qualified sales opportunity, an active CRM user, or a recurring subscriber. Analytics definitions would need to keep those categories separate.
A credible initial commercialization study would identify a narrow team profile, document its existing workflow, and test whether the public resource layer or separate CRM/POS solves a budgeted problem. Permissioned interviews and synthetic workflow trials should precede claims about savings. If pilots are used, success criteria should be agreed in advance and include adoption, repeat use, support burden, and willingness to pay.
Distribution is a material risk. Mortgage information is widely available from agencies, lenders, media, and software providers. Search visibility and content production alone do not demonstrate durable demand. There is no independently verified traffic series, sales funnel, paid cohort, or software-spend estimate in this assessment. The opportunity is described by use case rather than an unsupported market-size headline.
Competitive landscape
Acquire, build, or use an existing service.
A buyer has several alternatives: license an existing mortgage CRM, adopt a borrower point-of-sale service, use free agency data and calculators, or build a tailored resource site. Shape and Floify are category examples, not validated Studio 1003 integrations. No feature-parity matrix, competitor pricing comparison, or superiority claim is made. Current vendor terms and demonstrated buyer requirements would be needed for that analysis.
The public repository offers an assembled implementation: mortgage calculations, source-aware market presentation, editorial infrastructure, and a coherent interface. Acquisition could be useful to a buyer that needs those particular components and can reuse them legally. A buyer needing only one calculator might reasonably implement it independently or license an alternative. Existing code is valuable only to the extent it fits the intended project.
The buy-versus-build exhibit separates delivered components from adaptation work. It does not promise a specific time saving. Replacement effort is estimated by functional work package, assuming contemporary frameworks and assisted development. Integration, independent security review, license diligence, operating setup, and maintenance remain costs. A strategic premium requires buyer evidence rather than a persuasive interface.
Technology and architecture
A standalone web application with explicit external dependencies.
The public application uses server-rendered Astro pages, TypeScript modules, custom CSS, and browser-side interactions. Shared mortgage functions separate core calculations from presentation. Server routes handle market data and controlled publishing workflows. The design favors direct links and crawlable resources, with JavaScript used where it adds useful interaction rather than hiding essential document content.
Persistent editorial and subscriber data uses PostgreSQL. External services supply economic data, email transport, challenge verification, and assisted content generation. Those service relationships, quotas, source licenses, and credentials are not automatically transferable assets. A buyer would need its own approved accounts or documented assignment rights. Public architecture summaries intentionally omit credentials, internal addresses, and exploitable operational detail.
Development safeguards prevent live mail and publishing operations during ordinary preview testing. Server-side input and challenge validation complement browser controls. Automated tests and dependency checks are useful evidence but not substitutes for an independent security assessment, backup restoration, or a clean deployment under buyer-controlled infrastructure. Scalability, support effort, and recovery objectives have not been established through representative load or disaster-recovery exercises.
Business model
Subscription positioning is not verified revenue.
The website describes subscription access for individual loan officers and teams, with enterprise discussions handled separately. Those public commercial descriptions concern the broader CRM/POS proposition. This assessment does not infer active paid subscriptions from pricing pages or the presence of payment-related packages. It has no reconciled invoices, payment ledger, executed customer contracts, or measured retention cohort.
The public resource application could support several business strategies: education alongside a paid workflow product, branded tools for an existing mortgage audience, or a focused information service. These are proposed commercialization paths, not implemented revenue streams. Each would need its own support, compliance, distribution, content-maintenance, and data-license economics before an investment case could be underwritten.
Operating costs remain an evidence gap. Hosting, database capacity, source access, email volumes, model calls, editorial review, and maintenance all depend on usage and service terms. A buyer should request actual invoices and permissioned usage records over a defined period. No fictional gross margin, customer-acquisition cost, lifetime value, or annual recurring revenue is used in the current software assessment.
Traction and commercial evidence
Engineering milestones are evidence. They are not customer traction.
The assessment begins from a recorded repository revision and a clean Development baseline. Automated tests cover selected calculator scenarios, market-display integrity, token-validation behavior, contact validation, email rendering, and runtime safeguards. Build and type checks establish that the code can compile under the tested environment. Browser checks add evidence about the visible public experience and its interactions.
This evidence supports a functioning public-resource foundation. It does not establish active users, customer retention, transaction volume, service-level performance, or economic outcomes. The memorandum contains no fabricated growth chart and does not import usage claims from other Mektra applications. Owner statements would be labeled as owner reported until independently reconciled to a defined source and period.
Commercial diligence should request a concise evidence package: permissioned analytics with bot filtering and event definitions, sales records, signed agreements, invoice reconciliation, refunds, churn, and support history where applicable. Missing evidence is not proof of zero activity, but it prevents a reliable claim of traction. No commercial premium is assigned to an unverified metric.
Valuation methodology and results
Replacement cost, buyer utility, and price are different questions.
Modern replacement cost is estimated by decomposing the pre-investor repository into functional work packages. Each package has low, central, and high effort assumptions. The private model identifies its wage source, separately labels the burden assumption, and excludes this investor system, the external CRM/POS runtime, proposed integrations, and customer data. A published labor wage is not a contractor quote or proof of historical development cost.
Remediation and transfer work is estimated separately to avoid double counting. It includes independent verification, data and service-rights review, deployment and recovery preparation, and buyer-specific adaptation. The internal scenario model compares the replacement effort for a buyer-selected reusable subset with those costs. It is a conditional avoided-cost sensitivity, not a market-clearing price. Unsupported strategic premiums and ARR multiples are excluded.
The official public financial assessment remains under owner review. No internal estimate or negotiation target is embedded in this document or the public scenario controls. The public exhibit uses neutral effort units with no currency conversion. An approved financial snapshot would require an explicit owner action, a named revision, a reason, and a publication record. Actual transaction value could be materially lower, including no viable offer, because demand, rights, and transfer costs are not established.
Acquisition thesis and assets
A possible starting point, not an automatic strategic premium.
A mortgage operator with an existing audience might consider the resource layer as a branded education and scenario-discussion tool. A software vendor might value specific calculation or publishing components that complement its own product. An independent operator might consider maintaining the public information service. These are buyer hypotheses, not expressions of interest, commitments, or evidence that an acquisition is preferable to licensing alternatives.
The candidate asset perimeter is the owned source for this repository, eligible documentation and design assets, and any specifically negotiated domains or service agreements. Inclusion remains subject to ownership and licensing review. The separate CRM/POS codebase, third-party datasets, subscriber information, shared portfolio systems, and investor personal information are not assumed to be included. A software asset purchase is not automatically an equity purchase in a separate company.
A transfer should follow a written schedule of assets and exclusions, contributor assignments, dependency and data licenses, credential replacement, migration responsibilities, and acceptance tests. No repository artifact can establish legal title on its own. Missing ownership evidence is a gating issue even if the engineering assessment is strong. Price, deal structure, warranties, and transition support require separate negotiation and legal advice.
Roadmap and growth opportunities
Earn stronger claims through evidence-led milestones.
The next technical milestone is a controlled transfer rehearsal: provision approved services, restore synthetic or expressly authorized data, execute representative workflows, and document recovery. That exercise should be independent of the current developer environment. In parallel, the team should maintain source dates and program assumptions in calculators and market resources, with regression tests for behavior that could materially affect user decisions.
The next product milestone is authorized verification of the separate CRM/POS application. Evidence should cover borrower intake, role boundaries, persistence, pipeline ownership, and supported LOS handoff paths. Provider-specific integrations should be described as planned until documentation, permissions, and sandbox evidence support a stronger classification. A polished diagram cannot substitute for a completed workflow.
The next commercial milestone is a bounded pilot with clear measurement, privacy terms, and support responsibility. Paid demand, repeat usage, and a sustainable maintenance burden would strengthen the business case. None is guaranteed. Roadmap items are planned capabilities or diligence activities, not assets already included in replacement cost, committed delivery dates, or projections used to inflate current value.
Risks and limitations
Make the unresolved questions explicit before a transaction.
Key uncertainties include commercial demand, contributor rights, third-party licensing, source reliability, operational cost, and the scope of the separate CRM/POS product. The readiness score awards no points for missing ownership or commercial records. Its technical component reflects observed controls and tests; it is not a certification or a direct multiplier applied to acquisition value.
Market data and mortgage guidelines may be revised or delayed. Calculators depend on user-entered assumptions and do not provide a lending commitment, individualized financial advice, or underwriting approval. AI-assisted editorial software requires source verification and human oversight appropriate to the content. The absence of a known issue in a limited test does not establish regulatory compliance, perfect accuracy, or freedom from defects.
This is an informational software assessment and a channel for private discussion. It is not an offer to sell securities, a binding asset-sale offer, an appraisal certification, or a solicitation with approved investment terms. No funding request, return promise, named customer case study, or legacy white-paper performance statistic has been carried forward without supporting evidence. Confidential materials are withheld from public routes.
Supporting evidence and sources
A source must support the precise claim attached to it.
Repository evidence supports implementation and limited functional verification. Development verified means the stated behavior was checked in the authorized Development environment; it does not mean every edge case or Production operation was tested. Owner reported means a statement has not yet been independently reconciled. Estimated identifies analytical assumptions. Planned identifies work not included as implemented value. Not yet verified identifies an unresolved question.
The public source register links to CFPB HMDA context, Freddie Mac survey methodology, FRED terms, the BLS labor reference, and category alternatives. Sources were reviewed for this memorandum on the assessment date. No transaction-comparable dataset was available, no market-size model was validated, and no outside company is represented as a partner or interested buyer. Public sources may change after review.
The old image-based white-paper draft was inspected as historical input. Its funding request, performance statistics, proposed operating scope, credentials, and enterprise case references are not adopted as facts. The current document and PDF derive from one content source and share a version and assessment date. Material revisions require a new review; approval does not silently extend to changed financial assumptions or newly added confidential evidence.
10 / Private discussion
Discuss fit, not a published price.
Share whether you are exploring an asset acquisition or a strategic investment conversation. No investment terms or sale offer are made here.
Private inquiry · no automated commitmentA private conversation
Two paths. One clear starting point.
Discuss acquiring the software assets or supporting the next stage of development. No securities terms or commitments are offered here.
This inquiry channel is awaiting release approval. No investor information is collected through this page.
Questions worth asking first.
Is Studio 1003 a loan origination system?
No. The broader thesis is a mortgage CRM/POS-first workflow layer intended to support LOS handoff or integration, not replace an LOS.
Is the CRM/POS included in this audit?
No. The authenticated CRM/POS is separately hosted and outside the public software scope and current estimate.
Why is there no public valuation?
The official financial assessment remains under owner review. No private model inputs or estimates are imported into this public experience.
Does the readiness score establish security certification?
No. It reflects the limited evidence listed here. Independent penetration testing, ownership review, and clean-room transfer remain open priorities.
Are the tools financial advice or loan quotes?
No. Calculators are scenarios based on inputs. Rates and indicators provide market context, not an individualized borrower offer or underwriting decision.
What does Development verified mean?
The behavior was checked in the authorized Development environment. It is not Production certification and does not imply exhaustive edge-case coverage.
Source register
Reviewed for this assessment on 2026-10-17. Each source supports the scope described in its note.
Development assessmentRepository inspection, baseline automated tests, and Development browser verification. Not a Production certification.CFPB: Home Mortgage Disclosure Act dataReviewed October 17, 2026. Market context, not a measure of addressable software spending.Freddie Mac: Primary Mortgage Market SurveyReviewed October 17, 2026. Weekly national survey methodology; not an individual loan quote.FRED: Economic data and usage termsThird-party series remain subject to their source licenses and revision policies.BLS: Software developers, QA analysts, and testersReviewed October 17, 2026. Wage evidence for the private cost model, not a vendor quotation.Shape: Mortgage CRMCategory alternative. No feature parity, price, or performance comparison is asserted.Floify: Mortgage point of saleCategory alternative. Provider compatibility with Studio 1003 has not been verified.
Methodology: repository inspection, selected baseline tests, build and type checks, plus Development browser verification. No Production certification, transaction comparables, market-size model, or verified customer economics. This is informational, not an offer, appraisal certification, or investment solicitation.