Sample data, clearly labeled
The showcased deals, contacts and itineraries are fictional. Website concepts and native prototypes are labeled so that illustrative work is not presented as a real client engagement.
Privacy & Security
Trust starts with
clear boundaries.
What is collected, where it goes, and who can access it should be clear. Here is how this portfolio works today, and what we would define together for a production project.
Portfolio notice · Updated October 26, 2026 · Portfolio terms ↓
In this portfolio,
today.
Specific protections and limits, grounded in the current implementation.
No portfolio collection forms
The portfolio has no contact-form backend, customer account database or analytics. The quote and booking examples demonstrate local interactions; they do not send a request or make a reservation.
Local storage in the new prototypes
Relay, Roam and Mise save their workspace, itinerary or meal-plan data in app-local storage. Their current builds contain no cloud sync, account service, analytics SDK. Sharing or exporting data is an explicit user action.
Clear storage limits
These three prototypes use UserDefaults for their local demo data. They do not implement an additional encrypted vault. Their reset actions require confirmation. Sensitive production records would need storage and access controls chosen for that project.
No service secrets in this frontend
No service credentials are embedded in browser assets or the three native prototypes. Source scans found no service secrets in the reviewed files. This is a scoped source check, not a security certification.
Review access through the host
The portfolio’s visibility is configured through its hosting platform. The owner controls whether the portfolio is public or restricted through hosting settings. Public viewing does not grant editing access. Any sign-in, access enforcement and hosting infrastructure are provided by that platform; they are not custom authentication built into this page.
Where information
can leave the page.
Privacy includes the services around a website, not only its own forms.
Hosting and sign-in
The host handles page delivery and review access. Hosting and authentication services may process routine request information and authentication data under their own terms. This page does not claim that infrastructure logs or authentication cookies do not exist.
Earlier website concepts
Fernwood, Saltbox and Fifth & Fade load some resources from Google Fonts and Unsplash. Fernwood also loads animation libraries from cdnjs and unpkg. Those requests expose normal request information to the resource providers.
The three newer concepts—Still, Daylight and After Hours—bundle their photography locally and use no external scripts or font service.
Links and shared content
Email links open your chosen email service. Native export and share actions use the device’s share flow, and the person chooses the destination. Those destinations have their own data handling.
For a client project,
define the controls first.
The following are scoping and implementation requirements to agree before production—not claims that every control exists in these prototypes.
Collect only what the feature needs
Map the fields, their purpose, where they are stored, and which services receive them. Identify sensitive records early and avoid placing them in demos, public assets or logs.
Give each person the right access
Define staff and representative roles, then implement and test authentication and server-side authorization for the actual product. Client-side hiding alone is not an access control.
Keep credentials in the right place
Use server-side secret storage for service credentials and appropriate protected device storage for app credentials. Separate development and production configuration, with a plan to rotate exposed credentials.
Plan the data lifecycle
Agree retention, deletion, export and backup needs, including how restoration will be tested. The implementation and the published data notice should describe the same behavior.
Verify the release
Review dependencies, permissions and secret handling; test expected and denied access paths; and establish the project’s deployment and recovery process. The level of review depends on the data and the work involved.
Portfolio terms
& project expectations.
This notice explains how to use the demonstrations. A paid engagement needs a separate written agreement.
Demonstrations, not operating businesses
The six websites are self-initiated concepts. The three iPhone apps are working portfolio prototypes shown through simulator captures. Sample customers, testimonials, prices and business activity are illustrative; they are not client endorsements or commercial results.
Explore with sample information
Do not enter confidential or sensitive information into a demo. Booking and quote previews do not place orders, make reservations or deliver services. Sample calculations are demonstrations, not estimates for a real project.
Content and third-party materials
Portfolio presentation and original project work are shown by Yoseph Bagighni / BrightWeb Solutions. Photography and other third-party materials remain subject to their respective licenses and credits. Viewing the portfolio does not grant a license to reuse its materials.
A separate agreement before paid work
Scope, deliverables, pricing, payment milestones, revisions, timeline, source and design ownership, third-party fees, support and launch responsibilities should be agreed in writing. This portfolio alone is not a proposal, a service-level commitment or a guarantee of business results.
Questions and corrections
For privacy questions, content corrections or project enquiries, email yosephb@brightwebservices.com. Please describe the relevant page without including passwords, financial records or other sensitive information.
Ask before
connecting the data.
This page describes the portfolio and its three native prototypes. Future client products need their own implementations and data notices. No security certification or independent penetration test is represented here.