Choosing how it should work
Build a capability, use a provider or narrow the first release? Compare the complete paths, including what each one depends on.
Financial products · Payments · Partner models
I help founders and product studios assess decisions between payment infrastructure, partner responsibilities and what people actually need to do—including whether a proposed change should be built at all.
Direct work with me. Written exchanges. A defined result.
01 / Where I contribute
You have a product, a direction or a working prototype. One question is holding up the next move.
Build a capability, use a provider or narrow the first release? Compare the complete paths, including what each one depends on.
The APIs exist. The complete flow still needs ownership: who reserves funds, executes, confirms, handles exceptions and answers the user?
The system has a reason for a delay or restriction. Can the person understand it, complete the task and recover when something changes?
02 / A sample of the work
A simplified example, not a client case.
Explore how one uncertain result changes the decision.
CHOOSE THE PAYMENT RESULT
A person makes a QR payment. Your app sends an instruction to a local payment provider. The merchant's receipt and your app's status may arrive at different times.
The instruction was sent. A definitive execution result has not arrived.
That paying again or switching providers is safe. The first payment may already have completed.
Keep the reservation, query the original payment and reconcile its status before allowing a new execution.
Delay the confirmation after a successful payment. The system must neither pay twice nor release funds prematurely.
A useful review connects the user's next action to what the system can actually establish.
Independent review / Reap
Reap's published screens already warn about collateral repayment. This sample removes the unsupported diagnosis, distinguishes credit limit from spending capacity, and compares what to verify next—including when to leave the product unchanged.
Independent analysis of public material. Not a client engagement, endorsement or measured result.
Read the complete review03 / The first engagement
A focused written review of one product flow or partner-model decision, within one agreed market.
YOUR WRITTEN DECISION BRIEF
Participants, money movement, user actions and the responsibilities between them.
What changes with each approach, what it costs operationally and where the dependencies move.
The reasoning behind it, the assumptions it relies on and the facts that could change it.
Questions for your team and providers, meaningful tests and conditions for proceeding.
If an existing provider is the better answer, the review should make that clear too.
For product studios
Your team has research, product requirements or user feedback. Several directions look plausible, and one decision needs a closer look before development.
I take on a separate written analysis of a product flow or partner-model choice, using materials your team is authorised to share.
Evidence, alternatives, a conditional recommendation and the next test. Include it in discovery or your discussion of the next delivery stage, without adding a permanent role.
Client communication, any new user research and implementation stay with your team. The recommendation may also be to narrow, defer or leave a proposed change unbuilt.
04 / The person behind the work
Independent product architect.
I work on the decisions between the user, the product and its partners.
I map how participants interact, which responsibilities belong to each of them, and what needs to happen for a user to reach the intended outcome.
You work directly with me. I use AI tools for research, analysis and language support; the judgment, recommendations and responsibility for the written work remain mine.
I look at the whole mechanism: what the person is trying to do, what the technology permits and what each participant is prepared to take responsibility for.
I do not yet have a public portfolio of client engagements. Read my independent Reap review to assess the approach. We can also agree on one small question for a brief written sample at no charge; a full review is a separate paid engagement.
05 / Before we start
No. Start with the decision, the intended user outcome and the main constraint. We agree the necessary materials and confidentiality terms before sharing sensitive architecture.
I will say so before proposing paid work. Legal opinions, compliance approval, security audits and production engineering require the relevant qualified specialists.
The first engagement is a written review. Detailed pilot design or further architecture work can follow under a separate scope. Development and live operations are agreed separately.
A short brief, targeted follow-up questions, shared documents and one clarification round. Your team can review and share the reasoning in its own time.
06 / Start with the question
A few lines are enough to establish whether I can contribute. No confidential information is needed for the first exchange.
I’ll first confirm the fit. Then we agree the scope, fee and delivery in writing.
solidprone@gmail.com · Direct correspondence with Alexey