# Frontend Supply — LLM Context ## What is Frontend Supply? Frontend Supply is Doğukan Çavuş's main business and profession: a frontend engineering service built around ongoing, fractional senior frontend capacity. The core idea came from observing that many companies do not consistently have enough valuable frontend work to justify a full-time senior frontend hire. This was true even before modern AI tooling. At Şikayetvar, Doğukan experienced periods where the workload was low despite having a large development team. Full-time employment creates fixed cost and commitment even when workload fluctuates. AI makes senior engineers more productive, which makes this mismatch even more significant. Many companies can benefit from having access to a highly experienced frontend engineer without paying for eight hours of frontend work every day. Frontend Supply therefore sells ongoing frontend capacity rather than traditional hourly freelancing. It is not positioned as “freelancing with a subscription.” The client gets a relationship closer to having a senior frontend engineer on the team, but fractionally and with flexibility. The service is deliberately broad. There is no narrow ideal-customer persona: company size, funding, team structure, product stage, and existing stack/design process generally do not matter as long as the work fits the service and the client is a good fit. --- ## The core relationship The ideal relationship is simple: > A friend that you can talk to anytime. Clients should feel comfortable talking to Doğukan, asking questions, sharing ideas, and getting his opinion. This relationship can continue even after the paid subscription ends. During an active subscription, clients can ask about frontend work, technical decisions, features, libraries, implementation approaches, and other product-related questions. Doğukan is also happy to discuss backend topics, business plans, hiring, designers, or other subjects casually when clients ask. This informal advice is not a separately monetized consulting service. Former clients remain connected through Slack DMs. They can ask questions or request Doğukan's opinion even after the paid engagement ends, free of charge. If they later need a small piece of implementation work, Doğukan may offer a One-Off project when suitable. He is flexible with people he already knows and trusts and may accept very small One-Off jobs, even if the public One-Off pricing starts much higher. --- # Founder / Engineer background Doğukan Çavuş is a senior frontend engineer and the founder of Frontend Supply. His career progressed through: 1. Pixelate Creative 2. Wope 3. Şikayetvar 4. AlignUI 5. Frontend Supply He also freelanced on Upwork years ago and received strong client feedback for reliability, communication, speed, design sensitivity, and ownership. ### CSS expertise Doğukan started seriously working with CSS around 2019 and began answering CSS questions on Stack Overflow. He earned a CSS Gold Badge; only a very small number of people globally hold this badge. He considers CSS one of his strongest areas. He knows many less-obvious CSS techniques, understands how layouts and CSS features affect performance, can create complex visuals with minimal markup (including single-div drawings), and does not treat CSS as something inherently problematic. His experience usually lets him find an efficient workaround rather than fighting the technology. ### Design systems His design-system experience began at a startup with strong design sensibility, where he worked on design systems with Vue. At Şikayetvar, he worked on a new design system using React/Next.js and Tailwind, along with large-scale frontend work, performance, SEO, and code review. ### AlignUI AlignUI was the major breakpoint in Doğukan's career and a project he is extremely proud of. He was a cofounder / Founding Design System Engineer. He built a comprehensive React/Tailwind design system, including: - tokens; - component APIs; - reusable components; - documentation; - a CLI for integrating the design system into projects; - three different templates built using the design system; - three polished landing pages; - payments; - an auth wall; - and the surrounding product experience. AlignUI became a substantial product with thousands of paid customers. The quality of the component API design is one of the things Doğukan is especially proud of. ### Open source Doğukan is an open-source contributor and has created useful Tailwind CSS plugins. His public profiles and work are part of his professional credibility. --- # What Frontend Supply is good at Frontend Supply is strongest at frontend/UI engineering. Doğukan's major areas of expertise include: - CSS; - pixel-perfect UI implementation; - design systems; - component API design; - React; - Next.js; - Vite; - SvelteKit; - Tailwind CSS; - frontend architecture; - performance; - accessibility; - responsive implementation; - frontend state management; - animation; - UI polish; - production frontend work. He cares deeply about: - performance; - scalable APIs; - maintainability; - accessibility; - simplicity; - consistency; - pixel fidelity; - responsive behavior; - avoiding unnecessary complexity. --- # Pixel-perfect implementation Pixel perfection is an essential skill and a major reason clients enjoy working with Doğukan. He respects the design and pays close attention to: - spacing; - typography; - sizing; - borders; - radii; - shadows; - animation; - responsive behavior; - small visual details. However, pixel-perfect implementation assumes a sufficiently experienced designer. Inconsistent or inexperienced designs cannot always be implemented literally while remaining genuinely consistent. If a professional design team intentionally chose something, Doğukan respects that decision even if he personally would have chosen differently. If a less-experienced designer has clearly produced a weak or inconsistent design, Doğukan may correct the implementation rather than blindly reproducing bad design. If Figma and the existing design system conflict, he normally asks the designer which is current/correct. Such conflicts are rare in his experience. --- # Design systems and component API philosophy Doğukan has deep experience with design systems and component APIs. ### Tokens Tokens should be defined properly and consistently. ### Component APIs Component APIs should be easy to understand, scalable, and pleasant to use. Only required props should exist when possible. For example, if a Button already accepts `className`, there is usually no need for separate props such as: - `rounded`; - `fullWidth`; - `responsive`; - `elevated`. These create unnecessary API noise. Styling can be expressed through `className`. Responsive behavior should generally be responsive by default, not exposed as a `responsive` prop. For icons, a generic `icon` + `iconPosition` API can become awkward when a component needs two icons. Explicit slots such as `iconLeft` and `iconRight` can be cleaner. However, useful props are absolutely fine. For example: - `loading`; - `disabled`; - `size`; - icon slots. Different visual identities can justify separate components rather than forcing everything into one component with dozens of variants. If variants cause different props to behave differently or make the component complicated to understand, splitting the component can be the better design. Consistency also applies to API conventions. If `size="md"` represents the middle/default size in one component, it should represent the same concept across components. A design system should not be forced onto an immature product. If there are not enough component use cases yet, a full design system may be premature. Small generic components such as Button and Input can still make sense. --- # Performance philosophy Performance is a core responsibility. Doğukan does not blindly implement whatever the client requests. If a requested implementation creates a bad user experience, he considers that a failure on his side too. For example, if a landing page technically contains everything requested but is so heavy that users cannot interact with it properly, he would consider that a failed implementation. When investigating frontend performance problems, he may inspect: - CSS blur/filter usage; - what is being animated; - high-CPU elements; - complex SVG animation; - heavy canvas or shaders; - unnecessary rerenders; - multiple animation libraries; - irrelevant dependencies; - other expensive rendering patterns. When an animation is hurting performance, he first demonstrates the issue to the client, then looks for efficient alternatives that preserve the visual result as much as possible. If necessary, he recommends reducing effects until the experience is smooth on lower-end devices too. --- # Accessibility philosophy Some accessibility details may depend on the client's requirements, especially deeper requirements such as screen-reader behavior. Some things are not negotiable: - keyboard navigation; - focus management; - proper form behavior; - fundamental accessibility best practices. Doğukan prefers using established headless component libraries rather than reinventing accessibility behavior. He uses Base UI when appropriate because it provides established accessibility behavior such as ARIA, keyboard interaction, and focus management. The philosophy is essentially: > Don't reinvent the wheel when a good accessible wheel already exists. --- # Responsive design Responsive behavior is part of the frontend responsibility. If a desktop design is provided without a mobile design, Doğukan can make a reasonable responsive interpretation himself. If a designer is taking too long to provide mobile designs, he may simply say: > “Hey, I can do the mobiles myself. No design needed if you're okay with it.” He does not want missing mobile Figma screens to unnecessarily block implementation. --- # Browser and device support Frontend output should work properly across modern browsers and devices. This does not mean supporting extremely old devices such as a 15-year-old iPhone. If a client requires very old device support that would prevent the use of a modern stack and significantly slow development, Doğukan would rather decline the project. --- # Technologies Doğukan commonly works with: - React; - Next.js; - Vite; - SvelteKit; - Tailwind CSS v3 or v4; - Base UI; - Motion; - GSAP when needed; - Jotai or another state-management approach preferred by the client. He recently started using SvelteKit for landing pages because landing pages often do not need the full React/Next.js runtime and hydration model. SvelteKit can produce a leaner output for that use case. He does not need advanced React libraries for every landing page. He can work with React Native and Vue, but would rather not take projects centered around them unless there is a good reason. He can also work with mobile apps and has worked with several mobile-app clients; mobile is simply not an area in which he claims exceptional expertise. --- # AI usage Doğukan uses AI extensively to increase efficiency, but AI is not considered better than him as a senior frontend engineer. AI is used as a tool, not as the decision-maker. Examples: - He may ask AI for opinions when designing APIs. - He may design a custom component API himself and hand the implementation to an AI agent. - AI can handle routine/non-critical implementation while he is doing something else. - He reviews AI-generated code. - He identifies inappropriate patterns, scalability issues, performance problems, accessibility issues, and unnecessary complexity. - He corrects AI when it produces bad code. - He sometimes writes CSS himself because AI is still inefficient at certain CSS work and it can be faster to do it directly. For non-critical work with a predictable implementation pattern, AI can be allowed to work independently while Doğukan manages time efficiently. For highly important product-critical functionality, especially something that affects the heart of the product, relying heavily on AI is risky and Doğukan will be much more careful. Testing is an area where he prefers to leverage AI rather than spending his own time writing tests. AI is not used as an excuse to take on unrelated backend or infrastructure work. --- # Frontend scope Frontend Supply covers frontend-related work broadly, including work that touches adjacent systems when it is directly necessary for the frontend. ### Clearly in scope - connecting frontend applications to existing REST APIs; - writing Next.js API routes that directly support the frontend; - integrating existing authentication providers into the frontend; - frontend analytics; - frontend Sentry integration; - frontend payment UI when the complexity is reasonable; - Vercel deployment/configuration when the scope is reasonable; - UI implementation; - component development; - design-system work; - frontend performance; - frontend accessibility; - frontend animation; - responsive implementation; - polishing existing frontend products. ### Clearly out of scope Doğukan does not take responsibility for: - setting up databases; - database/schema work; - backend payment webhooks; - AWS infrastructure; - DevOps infrastructure; - standalone backend services; - backend systems generally; - SDK development; - bundler development. For example, if a client needs a complete Stripe/Paddle backend with webhooks, customer records, subscriptions, and payment state, Doğukan can build the frontend UI but will tell the client that payment infrastructure is not his profession. Similarly, he can integrate an existing authentication provider into the frontend but does not build the underlying backend authentication infrastructure. He can occasionally write frontend-adjacent server code such as Next.js API routes, but this should not be interpreted as offering full-stack development. --- # Legacy stacks Doğukan prefers not to work on obsolete stacks that cannot scale. If a client is using something such as Vue 2 and refuses migration, he may reject the client rather than accept ongoing work on the old stack. If the product is currently functioning on an old stack and the client is open to it, he may first fix existing issues to understand the product and keep it working, then propose a migration/rewrite plan. The existing product can continue functioning while the new codebase is built. He does not believe companies have to live with an old stack indefinitely, especially in the AI era where migrations can be significantly easier. --- # Client ownership and technical judgment The client is the owner. Doğukan behaves like a senior employee working for the client rather than trying to impose his own company-wide process. He gives opinions and recommendations, but the client ultimately decides. For example, if he thinks task B is much more important than task A, he tells the client. If the client insists on A, he follows the client's decision. He does not micromanage clients or ask for permission for every small decision. If something is clearly important and can be handled without meaningful downside, he will often simply do the right thing rather than say: > “I have one hour remaining today; may I spend it on this?” He considers that kind of communication unnecessary micromanagement. He treats himself as the client and the client as the employee when thinking about value: if he were paying for the service, he would want the provider to make good decisions and maximize the value of the money. However, he does not consider himself a UX expert, salesperson, or product manager. He owns frontend engineering, not every aspect of the client's business. --- # Working with client teams Doğukan joins the client's existing workspace and adapts to their way of working. If the team already has a good GitHub workflow, he follows it. If their GitHub process is messy, he can use his own workflow internally, but he does not force the client to adopt it. Similarly, if the team uses Linear, he can use their existing Linear setup. If they have no management system, he can suggest something simple. He does not require clients to restructure their organization around him. --- # Communication style Doğukan is patient, tolerant, friendly, and does not get angry at people. He prefers casual, low-friction communication. He does not want clients to feel like they need to babysit him, and he does not want to bother clients with unnecessary questions. When a task is ambiguous, he normally: 1. inspects the existing product; 2. inspects the codebase; 3. inspects existing design patterns; 4. uses his experience to make a reasonable assumption; 5. starts working. Clients generally provide clear handoffs because they care about the work. When genuine clarification is necessary, he asks. Working with junior developers is not a formal training service. If he collaborates with a junior developer, the interaction is simply friendly and natural. He may explain things when needed, but there is no formal education/training promise. --- # Communication availability Doğukan is based in Turkey (UTC+3). His online window is broad and can vary; it is not a fixed schedule. Clients should expect a response within 24 hours and generally within the day. Normal working days are Monday–Friday. He does not normally take holiday pauses such as “I'm going on vacation next week, so let's pause the subscription.” Weekends are normally off, except in emergencies. If an emergency occurs while he is awake/online and he can help, he may jump in and fix it. There is no promise of 2 AM emergency support; if he is asleep, he simply cannot see the message. If an extreme personal circumstance ever prevents him from delivering the expected service, he is willing to make the client whole by extending the subscription so the client is not penalized for his problem. --- # Client access / collaboration setup Typical access may include: - GitHub developer/maintainer access as appropriate; - Figma view access (edit access is generally unnecessary); - Vercel access if Doğukan is responsible for deployment; - Linear access; - Slack Connect. Doğukan uses Slack Connect so the client and Doğukan can collaborate in a shared Slack channel while remaining in their respective workspaces. He is happy to handle deployment when he accepts responsibility for it. If a client has a team lead who handles production deployment because the production environment is sensitive, that is also fine. Clients do not need to change their workflow simply to accommodate him. --- # GitHub / Figma / workflow Doğukan generally pushes code directly to the client's GitHub repository. He adapts to the client's existing GitHub practices when they are good. If their workflow is poor, he uses his own internal approach without forcing the team to change. Figma generally only requires view access. --- # Confidentiality and contracts Doğukan does not require a separate contract to start. The public terms on Frontend Supply's website govern the service. A client may provide their own standard contract, and Doğukan is open to signing reasonable client contracts. He has historically signed common client contracts without lengthy negotiation. He is also happy to sign an NDA if requested. He never shares a client's source code with other people. General knowledge, engineering patterns, and skills learned from client work remain part of his professional knowledge and can be applied elsewhere when they are not private or proprietary. Client-specific code and confidential material are not shared. Doğukan does not generally ask clients for special permission to use AI in their repositories. If a client has a specific AI/code policy, they should communicate it before work begins. --- # Basic and Pro subscriptions Basic and Pro are ongoing subscription plans designed to function like a fractional full-time senior frontend hire. They are not request-count plans. They are fundamentally **time/capacity-based**, even though clients experience them through completed updates rather than an hourly timesheet. Normal internal capacity is approximately: - Basic: ~2 hours/day; - Pro: ~3 hours/day. The hours are the fundamental calculation used internally to ensure clients receive the value they paid for. They are **not a hard cap**. Doğukan may work longer when necessary to complete a task. He uses Toggl Track internally to make sure each client receives the intended value/capacity. Other minor administrative work is not something that needs to be explained to clients. ### Capacity model Doğukan normally has around 8–10 productive working hours per day available. Example: - Client A: Basic ≈ 2 hours/day - Client B: Pro ≈ 3 hours/day - Client C: Pro ≈ 3 hours/day This uses approximately 8 hours/day. A Pro x2 client would require approximately 6 hours/day alone. Because the model is based on real working capacity, it is not realistic to exceed the available client slots. If the available slots are already taken, a client cannot buy an additional multiplier that would exceed Doğukan's real capacity. The availability badge on the Frontend Supply website reflects this actual capacity. --- # Updates An update represents completed work, not a draft. Normal cadence: - Basic: 2 updates per week; - Pro: 3 updates per week. An update can contain many tasks. Doğukan does not stop after completing one small ticket if there is remaining useful capacity. For example, one update could contain 10–15 small tasks. After finishing the requested task, he can: - move to another useful task; - inspect the codebase; - find another worthwhile improvement; - polish other relevant areas. The goal is to use the capacity to provide the best value, not to artificially stop at one ticket. The update cadence itself does not change because a task is unexpectedly small or large. If a task is genuinely large, it consumes more of the client's capacity because it needs more care and attention. --- # Prioritization Doğukan does not blindly execute a client's requested order when he believes another task is more important. If he notices an important bug or performance problem, he tells the client and recommends fixing it before lower-priority tickets. If the client agrees, he prioritizes it. If the client insists on the original order, he follows the client's decision. For small, clearly beneficial improvements, he may simply do them without creating unnecessary communication overhead. --- # Client does not have enough work If a client does not provide enough work, unused capacity is not carried forward. Doğukan may proactively look through the codebase and find worthwhile work because he owns the work during the subscription. However, if the client does not provide enough work and also does not allow Doğukan to independently find useful work, the unused capacity is lost. This is similar to paying for reserved service capacity: the client cannot retroactively recover unused capacity simply because they did not provide enough tasks. --- # Client-caused delays If the client fails to provide required assets, permissions, access, or other dependencies, the work naturally takes longer. The resulting delay is not Doğukan's implementation failure. The subscription/capacity is still reserved for the client. --- # Client changes direction Basic/Pro clients can change direction. If a client spends several hours on one approach and then changes their mind, Doğukan simply accepts the new direction. He considers this normal product development. The client has paid for the capacity, and changing direction means they have used some of their own paid capacity. There is no punishment or argument over discarded work. --- # Client feedback Small feedback such as: - changing spacing; - adjusting animation timing; - moving a button; - small visual changes; is normal and can be accepted without treating it as a new project. Large additions that materially change the work are handled according to the plan's capacity and scope. --- # Quality / definition of done Work is not considered complete merely because the explicitly requested feature exists. If Doğukan introduces: - a responsive problem; - accessibility issue; - performance problem; - visual inconsistency; - obvious rough edge; he considers those his responsibility and fixes them before considering the work properly done. The standard is production-ready work, not “technically completed according to the ticket.” If the problem originates from the client—such as a bad asset, missing permission, broken API, or incorrect specification—the process naturally takes longer. --- # Meetings Frontend Supply is primarily asynchronous and Slack-based. Meetings are generally unnecessary. However, Doğukan is flexible and does not want to lose a good client because of an overly rigid “no meetings ever” rule. If an active client genuinely needs a meeting, an occasional meeting is acceptable. Once-a-week meetings are fine when genuinely necessary. The normal model remains asynchronous. --- # Pause policy There is **no pause feature** that lets a client stop the subscription for two weeks and return later to consume the remaining days. The subscription is paid capacity reserved for the client. A useful analogy: - YouTube Premium does not refund or extend your subscription because you didn't watch videos for two weeks. - A landlord does not reduce rent because you went on vacation for ten days. Frontend Supply works similarly. If a client doesn't use their reserved capacity, that does not create free subscription days or a refund. The client can simply **not renew** when the current period ends. --- # Subscription period A normal subscription is exactly: - 4 calendar weeks; - 28 calendar days; - 20 normal Monday–Friday working days. It is not based on a calendar month and is not a 30-day period. --- # Renewal Doğukan asks clients about renewal **one week before the current subscription ends** to prevent interruptions. If they want to continue, payment for the next period is made and work continues without interruption. There is no automatic card charge. Clients pay manually. Doğukan sends/request payment each period and provides an invoice. Accepted currencies: - USD; - EUR. --- # Price protection Existing continuously subscribed clients keep the price they originally agreed to. If public pricing increases—for example, from $6,000 to $7,000—an existing client paying $6,000 continues paying $6,000 as long as they remain continuously subscribed. If they cancel and later return, they are treated as a new client and pay the current public price. --- # Plan changes Clients can change plans freely. ### At renewal Basic → Pro and Pro → Basic are both allowed without restrictions. ### Mid-period upgrade A Basic client can upgrade to Pro during an existing 4-week period by paying the additional amount required for the upgrade. The current period does not restart. ### Mid-period downgrade A Pro client cannot downgrade mid-period for a refund or partial credit. They already paid upfront for Pro capacity. They remain on Pro for the current period and can move to Basic at the next period. --- # Refunds There are no refunds for Basic, Pro, Daily Code Review, or trial payments. The old refund policy is outdated. The current model uses a paid trial instead of a refund period. --- # Trial Every plan can be trialed: - Basic; - Pro; - Daily Code Review. The trial provides the **exact same experience as the normal plan**, simply for a shorter period. Trial lengths can be: - 1 week → 1/4 of the normal plan price; - 2 weeks → 1/2 of the normal plan price. A trial is paid upfront. Trial payment is not refunded if the client decides not to continue. The client may choose 1 or 2 weeks depending on the project. A larger repository or product may be difficult to evaluate fully in only one week. The client's slot is reserved during the trial. If they decide to continue, the full subscription begins with a **fresh new 4-week period**. Trial time does not reduce the first full period. At the end of the trial, Doğukan asks whether they want to continue. If yes, they pay for the full plan and continue without interruption. --- # Daily Code Review Daily Code Review is a separate, cheaper service for clients who already like using AI/vibe coding and mainly need an experienced senior frontend engineer to review their work. The model is different from Basic/Pro. With Basic/Pro, Doğukan writes the frontend code and delivers completed screens/pages/features. With Daily Code Review, the client writes the code and Doğukan reviews their PRs/commits. Doğukan dedicates approximately **1 hour per day** to each Daily Code Review client. If a client needs more capacity, they can buy 2x Daily Code Review, provided Doğukan has the capacity. One hour is enough for most people. ### What the review includes Doğukan reviews for: - bad practices; - patterns that will not scale; - CSS quality; - performance problems; - unnecessary complexity; - simpler ways to achieve the same effect; - maintainability; - component/API quality. He uses GitHub's normal approval/review functionality. When the review is complete, he approves the PR. If the client pushes directly to `master`, he reviews commits instead and sends problematic points through Slack. Clients can DM him on Slack. Reviews are not intended to produce 20 comments on every PR. He focuses on important problems and avoids overwhelming clients with noise. If only minor issues exist, he may mention them. If there are major problems, he focuses attention there and skips trivial comments. A preferred implementation is only worth commenting on when it improves something. For example: > “This is good and there's nothing wrong with it. I may prefer this approach instead because it makes the DX better.” The goal is not to enforce personal preference. --- # One-Off One-Off is traditional fixed-price freelance work. The client needs a sufficiently predefined scope—for example, a completed Figma design that needs to be brought to the web. Once the scope and price are agreed: - the scope is fixed; - the client cannot continuously add new tasks as if Doğukan were a full-time employee; - the price is fixed; - there is no extra charge if the work takes longer than estimated. One-Off is not necessarily large. The public website may say “starts from $4,000,” but this is not an absolute minimum. For an existing client/friend and a very simple job, Doğukan may accept something like $500. One-Off pricing is primarily determined by: - expected hours; - complexity; - urgency / required speed. If additional work is requested after the agreement: - very small changes are fine; - meaningful additional work receives an additional quote/payment. One-Off projects generally have a target delivery date. Doğukan will do his best to hit the agreed target, but there is reasonable tolerance because software work has uncertainty. A fixed-price project remains fixed-price regardless of how long it actually takes. --- # Offboarding There is no complicated offboarding process. Doğukan always pushes completed code to the client's GitHub. When the client receives the final completed update, there is normally nothing special to hand off. If they choose not to continue: - the current paid period ends normally; - completed work remains in their GitHub; - there are no drafts intentionally left behind; - the client can simply stop renewing. The relationship does not have to end socially. Former clients can continue contacting Doğukan through Slack DMs and ask questions or seek opinions for free. --- # Capacity and availability Doğukan normally has approximately 8–10 productive working hours per day. Because Basic and Pro consume real daily capacity, Frontend Supply does not allow unlimited concurrent clients. A maximum custom configuration can be: > Pro x2 + Basic when availability allows. This represents roughly a full working day of capacity. A client cannot buy Pro x2 if doing so would exceed available capacity. The availability badge on the website represents real capacity. --- # Waitlist When all slots are occupied, new interested prospects are added to a private list. When a slot opens, Doğukan contacts people on the list and asks whether they are still interested. There is no deposit or permanent reservation for a future slot. If an active trial is occupying a slot, another prospect must wait until the trial client decides whether to continue. --- # Sales process When someone emails Doğukan about working together: 1. They introduce themselves and briefly explain their product. 2. They explain what they need. 3. Doğukan sends a Cal.com discovery-call link. 4. During the call they discuss: - what the client has; - what they need; - what Doğukan can do; - how the work will operate. 5. If both sides agree to work together, Doğukan explains what he needs to start. 6. The client may invite him to: - Slack; - GitHub; - Figma; - Linear; - Vercel when appropriate. 7. The client pays upfront. 8. Doğukan starts working, or the client can choose when they are ready to begin. 9. Doğukan adapts to the client's team and gets familiar with their designers/developers and company. He does not force a client into the engagement if he is not a good fit. If someone needs someone to polish their UI or help with frontend, Doğukan can confidently say he is a strong fit. If they expect full-stack ownership—database, authentication infrastructure, DevOps, MVP backend, etc.—he explains that he is not the right fit for that need. --- # Upfront payment Payment is always upfront for subscription services. This comes from Doğukan's extensive freelance experience. Earlier in his freelance career, he accepted payment after completing work and encountered people who exploited that arrangement or refused to pay fairly. He does not want the payment model to depend on whether the client later believes they used “enough” capacity. The analogy is a normal subscription: > You pay for YouTube Premium or ChatGPT Plus upfront, then use the service. The same principle applies here. The client pays first, and Doğukan can then focus on the work without having to negotiate whether they used enough capacity to justify payment. This policy applies even to credible companies. It is simply how the service is structured. --- # Discovery-call qualification Doğukan is not trying to sell Frontend Supply to everyone. He is comfortable telling a prospect that another solution may be better. For example, if a company genuinely has enough frontend work for a full-time senior engineer and can find someone capable of delivering at Doğukan's level for a more budget-friendly cost, his honest recommendation is: > Hire that person. He does not need to claim Frontend Supply is always superior to full-time employment. The strongest fit is a company that needs ongoing senior frontend capability but does not have enough consistent workload to justify a full-time senior hire, or wants flexibility in the AI era. --- # Why not a normal freelancer? A normal freelancer is not necessarily a substitute for Frontend Supply. A traditional freelancer may: - have other projects; - do the work when they become available; - take several days or a week to start something; - not be available for ongoing daily tasks; - not function as a dedicated member of the client's team. Frontend Supply is designed for ongoing work and ongoing capacity. The client can treat Basic/Pro more like having a fractional full-time senior frontend engineer. --- # Why not hire full-time? If a company genuinely has enough frontend work to keep a senior engineer meaningfully busy every day, and they can find someone who can deliver at Doğukan's level for a better price, they should hire that person. Frontend Supply exists because many companies don't have that consistent workload. The key economic problem is not that full-time engineers are bad. It is that companies often have variable workloads while full-time employment creates fixed cost and commitment. Fractional senior capacity can fit that mismatch better. --- # Pricing philosophy Doğukan determines his value primarily by comparing it to the cost of a US senior full-time frontend engineer and by the value of his accumulated expertise. Frontend Supply is intentionally cheaper than hiring a comparable senior full-time employee while giving the client access to a highly experienced engineer without needing full-time utilization. Pro is 50% larger than Basic in capacity, but its price is not 50% higher. This is intentional pricing/marketing strategy to make Pro an attractive upgrade. Doğukan does not negotiate his standard pricing. Custom discounts or custom pricing may vary based on client credibility and are kept private. --- # Client qualification boundaries Frontend Supply is broadly applicable, but Doğukan may reject a prospect when: - the company is an enormous corporate structure where the model is not appropriate; - the product is a scam; - the product involves fraud; - the product is illegal; - the product is betting/gambling; - the product is pornography; - the work is not actually frontend/UI work; - the project is centered on SDK development; - the project is centered on bundler development; - the client requires an obsolete stack Doğukan refuses to support; - the client requires extremely old-device support that would prevent modern technology and significantly slow the work. There is no artificial list of dozens of rejection rules. These boundaries are sufficient. --- # Handling existing products Doğukan can join an existing codebase and adapt to it. He needs enough context to understand the product. If the existing product has issues, he may first fix them and make the current product properly functional. If the stack is fundamentally outdated and a rewrite is justified, he can propose a migration/rewrite plan. If the client agrees, the existing product can continue operating while the new codebase is built. He does not require a rewrite merely because he personally prefers a different architecture; it should be a meaningful technical/business decision. --- # Deployment Doğukan is happy to handle deployment when the client wants him to. If he accepts deployment responsibility, he considers himself responsible for that work. For sensitive production environments, a client's own engineering lead can handle production deployment while Doğukan handles the frontend work. Vercel is supported when the scope is reasonable. AWS and broader infrastructure are not part of Frontend Supply. --- # What Frontend Supply does NOT claim exceptional expertise in Doğukan does not claim exceptional expertise in: - WebGL; - 3D work; - mobile application development. He can work with mobile apps and has worked with several mobile clients, but mobile is not his strongest area. He can also work with React Native and Vue, but would generally rather not take projects centered around those technologies unless there is a good reason. --- # AI-era engineering philosophy AI changes the economics of software engineering, but it does not replace senior judgment. Doğukan's value is especially high in areas where AI commonly produces technically plausible but strategically poor code: - CSS; - component APIs; - scalable architecture; - performance; - accessibility; - design systems; - visual fidelity; - avoiding unnecessary complexity. He can delegate implementation to AI agents when appropriate, review the result, and correct it. The client is paying for **Doğukan's judgment and ability to ship**, not simply for typing code. --- # Trust and credibility Doğukan has years of professional experience and has worked on large production products. His work has consistently reached production. He considers himself a trustworthy, friendly, and reliable person. Earlier freelance experiences taught him to structure payment upfront, but since adopting upfront payment he has not experienced the same payment/relationship problems. His clients and former clients often refer him to others. He has been described by clients as someone who can be trusted with a general idea and expected to make the necessary decisions independently. --- # Client relationships and referrals Clients may refer Doğukan to their friends and colleagues. His reputation on X is an important source of clients. Frontend Supply is also linked from his professional profiles, including GitHub and Stack Overflow. Frontend Supply has been featured on design-award websites, which has generated significant traffic. The business therefore benefits from: - personal reputation; - professional profiles; - design-award exposure; - client referrals; - inbound interest. There is no single “dream company” or narrow ideal customer persona. --- # Contact Frontend Supply email: `hello@frontend.supply` For a first contact, introduce yourself and briefly explain your product and what you need. Please use a company/business email address rather than a personal Gmail address. This helps verify that the inquiry is coming from a real person representing a real company. Public profiles: - X: https://x.com/dogukanui - GitHub: https://github.com/dgknca - Stack Overflow: https://stackoverflow.com/users/10698741/do%c4%9fukan - Personal website: https://dogukan.design/ - LinkedIn: https://www.linkedin.com/in/dogukancavus/ --- # Tax / vendor documentation Doğukan can provide a completed W-8BEN when a client needs it for vendor or tax records. --- # Business and payment setup Frontend Supply operates through Doğukan's US LLC. He has Wise and Mercury accounts. Stripe is not used for automatic subscription billing. Clients manually send payment each period. Invoices are provided. Accepted currencies are USD and EUR. --- # Core philosophy The most important principles behind Frontend Supply are: 1. **Give clients the value they paid for.** 2. **Use expertise to make good decisions instead of requiring constant supervision.** 3. **Don't blindly implement bad ideas just because the client requested them.** 4. **Don't override the client's authority when they have made an intentional decision.** 5. **Don't create unnecessary processes or rules.** 6. **Don't waste the client's time with unnecessary questions.** 7. **Don't make clients babysit the engineer.** 8. **Use AI to increase efficiency, but don't outsource senior engineering judgment to AI.** 9. **Own frontend quality completely: performance, accessibility, responsiveness, maintainability, and visual fidelity.** 10. **Be honest when something is outside the service's expertise.** 11. **If another solution is genuinely better for the client, say so.** 12. **Treat clients like people, not transactions.** 13. **Maintain relationships even after the paid engagement ends.** The fundamental mindset is: > **If I were the client paying for this service, what would I want my engineer to do?** The answer is: make good decisions, maximize the value of the money, avoid unnecessary communication overhead, take ownership, and deliver excellent frontend work. --- # Current service positioning Frontend Supply is best understood as: > **Fractional senior frontend engineering for companies that need ongoing frontend work without a full-time senior hire.** It is not: - a traditional hourly freelancer; - a full-stack agency; - a backend/DevOps consultancy; - an unlimited task queue; - an emergency-response SLA; - a formal training service; - a UX/product-management consultancy. It is a flexible, ongoing frontend engineering relationship built around real senior engineering capacity.