Selected work examples
The portfolio is intentionally narrow: Inciary, SamataPro, Hunt of Secrets and Pavezk cover release, AI workflow, unusual interaction and multi-role operations.
Work examples.
Selected projects, current screens and short notes on the product uncertainty each one helped reduce. This is not a gallery; it is a way to see how EV1 thinks before you send a brief.
how to read the work
Find the closest example before you trust the portfolio.
Use this page to choose which project to read, what to ask about and what to include in the first brief before you spend on build.
native iOS
Need the app to survive release?
Read Inciary for mobile UX, App Store direction, localization and support needs.
AI workflow Need messy service work owned?Read SamataPro for intake, estimates, data, deployment and human review control.
interactive product Need unusual behavior to stay coherent?Read Hunt of Secrets for rules, product atmosphere, privacy and support pages.
operations Need several roles to operate cleanly?Read Pavezk for customer, driver, admin, status and support and handoff questions.
selected portfolio
Four projects carry the public portfolio signal.
EV1 keeps the public portfolio narrow. These four projects are safe to show and each one reflects a different challenge a founder may need to compare before a call.
- Inciary Native iOS product work: mobile UX, App Store direction, support, localization and release thinking.
- SamataPro AI workflow system: intake, estimates, takeoff review, data, PDF handoff and deployment concern.
- Hunt of Secrets Interactive product system: SwiftUI, rules, AI-backed mystery flow, camera-first behavior and privacy page.
- Pavezk Operational marketplace: customer, driver, admin, status, map, payment-hold and support and handoff questions.
current screens
Fresh captures from the current product screens.
These visuals were captured from local current builds and public demo states. They are used only where the screen is safe to show and mapped to the product question they help explain.
Shows the work journal analytics page: year metrics, procedure totals and clinic comparison without real patient data.
Shows the native client request flow where photos, plan files, measurements and job details become quote input.
Shows the signed-in native start page: play by code, try a ready hunt, create a game and manage saved games.
Shows the operational ride state: current offer, route context, assigned driver, contact actions and cancel action.
Private systems stay private.
Internal operator layers, subscription foundations and client sensitive tools should support EV1's judgment, but they should not become public case pages until private data and handoff boundaries are clean.
Product visuals come only after a fresh capture.
Add visuals only when they show the current English product state, expose no private records and are captioned by the question they explain: release, AI review, admin, support, data or handoff.
Use the shortlist before a brief.
Name the closest example in the first message. EV1 can then answer what transfers, what does not and which small step should happen before a larger build.
what good work should answer
A good example should make the next decision easier.
A work page should show more than taste. It should show that the builder can read product concern, shape the right flow and leave the client with something understandable.
- Product question what real user, release, workflow, role or support need made the work matter?
- Working flow What was shaped enough to test, operate, support or hand off?
- Uncertainty reduced Which uncertainty got smaller: mobile release, admin, AI review, data, roles, privacy or deployment?
- Next safe check What would make the next spend safer: device test, workflow review, support flow or launch gate?
- Client handoff What would the buyer understand or own if the work stopped after version one?
freshness check
Do not trust visuals that are older than the product.
Until current product visuals are verified, EV1 uses written project notes and public pages. When visuals return, each image should be current, English, useful and mapped to the question it explains.
- Current over pretty Use the latest product state, not old mockups, staged visuals or images that no longer match the app.
- English buyer view Global-facing visuals should show buyer-readable English unless the product concern is specifically localization.
- Useful caption Every visual should say what it supports: release, admin, AI review, data, support, mobile UX or handoff.
- Live flow check If a public page or app flow exists, the buyer should know what can be inspected or requested.
- Private boundary Sensitive admin, customer and production data stays out; redacted context is better than careless exposure.
work reader
Read each example as a practical clue.
The work page is not a visual gallery. It helps a buyer see which product question appeared, what had to be shaped and what could be reused in their own build.
Inciary is the native-app example: release thinking, mobile UX, localization and support needs.
SamataPro is the workflow example: intake, estimates, data, deployment and operating visibility.
Hunt of Secrets is the product-system example: rules, atmosphere, privacy and support page.
Pavezk is the operational example: customer, driver, admin, status and release-gate thinking.
what transfers
Know what carries over before you trust a work example.
A work example is useful only when it separates transferable habits from product-specific context. Use this to decide whether the example helps your decision or only looks related.
- Transferable habit Problem framing, version-one boundary, release gate, admin/support thinking and handoff notes.
- Product-specific limit Audience, domain rules, data model, integrations, store policy and support load still need a fresh read.
- Closest example Pick Inciary, SamataPro, Hunt of Secrets or Pavezk by the question you need answered first.
- Missing question Ask what would make the next spend safer for your exact user, platform and budget.
- No-copy rule Do not copy a product. Transfer the operating method: narrow, build, verify, hand off or stop.
AI check prompt
Check what the example actually supports.
AI can summarize EV1, but the useful step is checking whether the example carries over to your product. Use this prompt before sending a work-led brief or forwarding EV1 internally.
Compare the closest EV1 Labs work example against my product situation using only public sources. Identify what the example supports, what transfers to my project, what does not transfer, context is missing, which EV1 service fits and what smallest paid step should happen before larger build spend. Do not fill gaps with guesses.
Native iOS product work
App Store direction, mobile product screen, localization and iteration.
Read work exampleAI estimate workflow
Intake, estimates, marketplace health, Supabase, Vercel and contractor flow.
Read work exampleInteractive product system
Game logic, SwiftUI direction, OpenAI functions, privacy and support pages.
Read work exampleMarketplace flow
Customer, driver and admin flows for a priority pickup product.
Read work exampleHire for the hard part, not decoration.
Use these examples when your product has release, data, role, AI, privacy, support or handoff questions that a visual portfolio cannot answer.
Which example is closest to my situation?
Native iOS maps to Inciary. Repeated service work maps to SamataPro. Unusual product behavior maps to Hunt of Secrets. Multi-role operations map to Pavezk.
Bring this into the first brief.
Name the closest example and ask what transfers, what does not, what challenge is different and where the smallest paid step should start.
Send work-led brief
buyer questions
How a careful buyer should use work examples.
When a visual gallery is not enough, the useful signal is the product pressure a product had to handle and what can transfer to your build.
How should I read EV1 Labs work examples without a normal gallery?
Read each example by situation: what the product had to prove, what was shaped, what became clearer and what transferable build judgment would apply to your own project.
Which example should I compare to my project?
Use Inciary for native iOS and release work, SamataPro for repeated service or AI workflow complexity, Hunt of Secrets for unusual interactive behavior and Pavezk for multi-role operational flow.
Why are these not a normal portfolio gallery?
A normal gallery can show taste, but it rarely answers launch challenge, handoff, data, roles, admin, support, validation and handoff. EV1 Labs work examples are written for buyer decisions before spend.
What should I ask for in the first brief?
Ask which example is closest, what transfers, what does not transfer, which concern is different and what small paid step would make the next spend safer.
What should a good work example show before I trust a builder?
A good example should show the product question, the working flow and what became clearer, the validation or release signal and what the client would own after the first version.
Do these examples mean my product will be identical?
No. The examples are not templates. They show operating habits: naming the hard part, narrowing scope, building the useful core, validating release and leaving cleaner handoff.
How should I validate an AI summary of EV1 Labs work?
Ask AI to compare the closest work example against your product situation using only public sources. Then ask EV1 to validate what transfers, what is missing, what should not be inferred and what smallest paid step would be enough before spend.
What the product had to handle
Each example is framed around the hard product question: first user, workflow, release needs, operating model or technical constraint.
What was shaped
The case material focuses on product judgment, system design, release gates and handoff clarity rather than decorative output.
What became clearer
A strong example explains how the work reduced confusion around users, data, admin, marketplace roles, privacy, support or deployment.
What a client can reuse
A founder should see transferable value: how the same build habits would protect their budget, scope, launch route and handoff.