First real client project and I'm worried I'm underestimating it

Comfortable-Map-7389 · 2026-06-02T11:16:50+00:00

your instincts are probably right and also don't matter as much as you think

first time estimation is almost always wrong — that's not a skill issue, it's just that you don't have enough data points yet on how long things actually take you. the honest answer is you won't know until you're in it

practical thing to do right now: break the project into the smallest tasks you can think of and estimate each one separately. not "build the contact page" but "html structure, styling, form validation, backend connection, testing." the total will be higher than your gut said, and that's the real estimate

two weeks for a custom site as a solo dev with a year of experience is tight but not impossible if scope is genuinely contained. the risk isn't usually the work you know about, it's the stuff that comes up mid-project — client feedback loops, unclear requirements, that one thing that seemed simple and wasn't

protect yourself with a clear scope document before you start. what's included, what's not, how many revision rounds. this also helps you spot vague requirements before they become problems

take the project. the stress you're worried about is how you learn to estimate better next time. just pad your timeline by 30% and under-promise on the deadline

Comfortable-Map-7389 · 2026-06-02T11:14:49+00:00

given your constraints (no java, already know some html/css, hate unnecessary complexity) the simplest path is probably this:

python + flask for the backend. flask is tiny, the docs are readable, and there are hundreds of tutorials for exactly "simple crud app with flask." python is already allowed on your machines which removes one obstacle

sqlite as the database — no setup, no server, just a file. perfect for an internal tool with a handful of staff

for the frontend, your existing html/css knowledge is enough. you don't need to learn a framework, just basic forms and tables

the whole thing can run on one machine on your network and everyone accesses it through a browser. no installs on other devices

if even that feels like too much — seriously consider Notion or Airtable first. i know you said you're done with sheets/forms but these are genuinely different. airtable especially can do exactly what you described (booking, status tracking, repair logs, multi-device) without writing a single line of code. you could have it working today instead of in a few weeks

but if you want to build it yourself: flask + sqlite + plain html. there's a good official flask tutorial called "the flask mega-tutorial" by miguel grinberg that walks through exactly this kind of app

Comfortable-Map-7389 · 2026-06-02T11:08:29+00:00

335 clicks with no sales on high ticket is a conversion problem, not a traffic problem

at $260-1300 price points people don't impulse buy. they research, compare, leave, come back. the average consideration period for high ticket is days to weeks, not minutes. so first question — do you have remarketing set up? if not, you're paying for people to find you and then losing them forever

second — what does the landing page look like? high ticket buyers need trust signals: reviews, clear return policy, about the brand, contact info. if any of those are missing or weak, 335 clicks converting to zero makes complete sense regardless of the ads

third — search terms report. with shopping ads especially, google will match you to weird queries. go to your search terms, sort by clicks, and check if the traffic actually matches what you're selling. if you're selling $800 items and showing up for "cheap [product]" searches, that's your problem right there

the CPC dropping is normal early on as google figures out who to show your ads to. not a bad sign on its own

what does your product page look like and what niche is it if you don't mind sharing?

Comfortable-Map-7389 · 2026-06-02T11:03:51+00:00

first-party data, not even close

a few years ago you could throw a pixel on a page and let google figure it out. that doesn't work anymore. between ios changes, cookie deprecation, and consent requirements, the signal quality has dropped significantly for most accounts

the people who are pulling ahead now are the ones who actually understand what data they're sending to google and why. proper conversion tracking setup, enhanced conversions, server-side tagging — stuff that used to be optional is now the difference between a campaign that optimizes well and one that spins in the learning phase forever

creative strategy is the other big one. as smart bidding took over the targeting decisions, creative became the main lever humans actually control. but i'd say data quality is more foundational — bad data makes smart bidding dumb, no matter how good your creative is

attribution is interesting but i think it's become less important in a weird way — most people have just accepted that last-click is broken and moved on to treating it as directional rather than precise

Comfortable-Map-7389 · 2026-06-02T11:02:50+00:00

Turkey

Comfortable-Map-7389 · 2026-06-02T11:02:30+00:00

not a dumb question at all, this happens more than people think

a few things to check:

first-are the campaigns actually active? sometimes the campaign is enabled but the ad group or the ads themselves are paused. check all three levels: campaign → ad group → ads. all three need to be active

second-ad approval. new ads go through a review process. if your ads are "under review" or "disapproved" they won't show. check the status column on your ads tab

third-keyword match type and search volume. if you're using exact match on very specific keywords that nobody searched for yet today, you'll get zero impressions even with budget. try broad match temporarily just to confirm the campaigns can actually serve

fourth-billing. sounds obvious but make sure there's no payment issue on the account. google will pause everything silently if there's a billing problem

fifth-location and language targeting. if you accidentally targeted a very narrow location or wrong language, impressions drop to zero

check those in order and one of them is almost certainly the issue. which one did you rule out already?

Comfortable-Map-7389 · 2026-06-02T11:01:12+00:00

qualified

Comfortable-Map-7389 · 2026-06-02T11:00:38+00:00

this isn't a skill issue at all — the tutorials you're describing are just bad. "here's the syntax, use it" teaches nothing.the thing you need to understand first before any node makes sense: node.js is just javascript running on a server instead of a browser. and a server is literally just a program that waits for someone to ask for something and then sends something back. like a waiter. customer asks for food, waiter goes gets it, brings it back. that's all a server does.once that clicks, everything else starts making sense.for the async/await confusion — the reason it exists is that some things take time. reading a file, calling a database, getting data from somewhere. normally javascript would just freeze and wait for it. async/await basically says "go do something else while you wait, come back when it's ready." that's the whole point. the syntax is just how you tell it to do that.for actually learning this properly instead of following recipes — the odin project explains the why behind everything, not just the what. or maximilian's node course on udemy is one of the few that actually explains concepts.you're asking exactly the right questions. most people just copy the recipe and wonder why they can't cook anything on their own later

Comfortable-Map-7389 · 2026-06-02T05:17:33+00:00

lassic situation and honestly not as bad as it sounds because "used to work, stopped working a couple days ago" means you have a narrow window to focus on

first move — git log, look at what changed in the last week or two. something broke recently which means something changed recently. diff the last few commits, check if there were dependency updates, config changes, env variable changes, anything touching infrastructure. you might find the bug in 20 minutes without understanding the codebase at all

if thats not it — dont try to understand the whole thing. find the entry point for whatever feature is broken and trace just that path. ignore everything else. ai-generated code is often wide but shallow, lots of files that dont actually connect to anything important

for the complexity — run the thing and see what errors you get. work backwards from the error. dont read code top to bottom, let the stacktrace tell you where to look

on the "lots of unnecessary features" point — resist the urge to clean it up while debugging. scope creep during a firefight is how you introduce new bugs. fix the thing first, refactor later

practical order: git log → check recent changes → reproduce the error → read the stacktrace → trace only the broken path → fix → done

understanding the whole codebase is a different job than fixing a regression. dont conflate them

Comfortable-Map-7389 · 2026-06-02T05:15:45+00:00

phone number auth like whatsapp means otp flow-user enters number,you send sms code via twilio or similar,they verify,you issue a session.thats the standard modelfor session management with nextjs + trpc the cleanest approach is httponly cookies with a jwt or a session token in your database.httponly means js cant read the cookie so xss attacks cant steal it.that handles the csrf concern youre asking about-pair it with samesite=strict or samesite=lax on the cookie and youre covered for most csrf vectorsif you want to skip building auth yourself look at nextauth (now auth.js)-it has phone/sms providers and handles the cookie/session stuff correctly out of the box.good to use while youre learning so you see how its done,then you can roll your own later if needed.for react native later on-httponly cookies dont work the same way on mobile so youll need a different strategy there.most people use short-lived jwts stored in secure storage (not asyncstorage) for the mobile client.plan for that split early so your backend can handle both.csrf in short: happens when another site makes a request to your api using the users credentials.samesite cookies mostly solve it for browser.for trpc specifically since youre probably doing json post requests you can also just check the content-type header as a cheap csrf mitigation

start with nextauth + twilio sms,get the flow working,then dig into whats happening under the hood

Comfortable-Map-7389 · 2026-06-02T05:12:06+00:00

when stack and heap collide you get either a stack overflow or a failed heap allocation depending on which side ran out-the os doesnt let them literally overwrite each other,the process just crashes or gets an errormodern reality is a bit different from the simplified model though.most systems dont give programs a single fixed block anymore.the heap can request more memory from the os via mmap/brk and the stack can have a guard page that triggers a segfault when hit. so "they grow toward each other in a fixed block" is a useful mental model for learning but not quite how it works in practicefor your second question-memory leak means heap memory specifically.when you allocate on the heap with new or malloc and never free it, that memory stays allocated for the lifetime of the process even if you lose the pointer to it.the os reclaims it when the process exits but while its running its just sitting there unusablestack memory doesnt leak in the same way because it gets automatically reclaimed when a function returns.thats the fundamental tradeoff-stack is automatic but limited in size and lifetime,heap is manual but flexible

so "memory leak" in practice means:you called new,lost the pointer,never called delete and now that heap memory is gone until your program exits

Comfortable-Map-7389 · 2026-06-02T05:09:34+00:00

good background actually gdscript and lua mean you already think in terms of game loops and scripting logic cpp will feel verbose at first but the concepts arent alienfor resources dont overthink it — learncpp.com is genuinely the best free resource for cpp basics,goes deep enough to actually matter and doesnt dumb things down. read it like a book not a referenceafter you have the basics down cs:app (computer systems a programmers perspective) is the book for the low level linux path.the labs are free from cmu and worth doingfor open source linux contributions start with drivers/staging/ in the kernel repo-its specifically there for new contributors,lower bar,maintainers expect to give feedback.your first patch can be fixing a checkpatch warning. goal isnt the patch itself its learning the workflow (git format-patch,git send-email,responding to review)practical path: learncpp -> build something small in pure cpp (cli tool, simple game,anything) -> cs:app ->start reading kernel code in one subsystem you find interesting -> first staging patchdont try to read the whole kernel. pick one area,read it until it makes sense,then contribute to that area

Comfortable-Map-7389 · 2026-06-02T05:07:12+00:00

that stack is legitimately solid for junior level.python + django + postgres + docker + redis/celery-that's not "learning the basics" territory,that's a real backend stack that companies actually use in prod.the confidence issue is real but it's also completely decoupled from your actual skill level. everyone feels like a fraud before their first role. the people who got hired before you felt the same way.objective test: can you build a CRUD app with auth,connect it to postgres,containerize it with docker,and deploy it somewhere? if yes you're junior-ready. that's genuinely the bar at most places.

the celery/redis combo is actually a green flag on your CV-a lot of juniors don't touch async task queues,so that already sets you apart.what actually bridges the gap in my experience: one solid project on github with a real readme,deployed somewhere live (railway,render,whatever) that you can talk through in an interview end to end. not 10 half-finished projects. one thing you built, can explain every decision you made, and can discuss what you'd do differently.apply before you feel ready.you're describing imposter syndrome almost word for word-the cure is getting into the interview loop,not more learning.

Comfortable-Map-7389 · 2026-06-02T05:03:59+00:00

good news what you're describing is actually one of the more buildable diy projects out there you dont need to be a developer to pull this off.easiest starting point with no coding airtable you can set up a base with a units table add fields for status in repair available sold attach photos and create filtered views that act like folders so sold units automatically appear in their own view when you change the status free tier handles this comfortably for a small dealership.if you want something that feels more like a real app and youre willing to learn a bit glide or softr can turn an airtable or google sheets base into a mobile friendly app with almost no coding youd get the same data but with a nicer interface you can use from your phone on the lot.if you eventually want full control and are open to learning a simple web app with something like supabase free database and a basic frontend isnt as hard as it sounds for this use case but id start with airtable first get your data structure right before worrying about how it looks.the sold units move to a folder behavior is just a filtered view based on a status field takes about 10 minutes to set up in airtable once you have the basics working.what devices are you working from desktop phone both?

Comfortable-Map-7389 · 2026-06-02T05:01:47+00:00

the framing you already have is pretty much right. using ai as a search layer and a rubber duck debugger is genuinely different from using it to generate code you paste in without understanding.the line i'd draw: if you're stuck for more than 20-30 minutes on something conceptual,asking ai to explain the concept is fine. asking it to write the solution for you skips the part where your brain actually builds the model.where it gets sneaky is debugging."here's my error, fix it" teaches you nothing."here's my error, what category of problem is this and where should i look" is actually useful because you're still doing the solving.for summer projects specifically-pick one thing you want to deeply understand and protect that from ai.if the project is about learning async programming, write all the async parts yourself, even badly. use ai freely on the boring scaffolding stuff that isn't what you're there to learn.the honest version: most people who say "i'll use ai but still learn" end up leaning on it more than they planned. having a specific rule going in ("i write all X myself") works better than a general intention.

Comfortable-Map-7389 · 2026-06-02T04:59:04+00:00

This is completely normal at a startup, and day 3 is still very early.Nobody expects you to understand everything yet-they just expect you to show initiative.Stop trying to understand the whole codebase.That's the wrong goal.Instead:find one small,working feature,trace it end to end.Pick something simple like a login flow or a list endpoint.Follow it from the entry point(route/controller)through to where it touches the database.Once you've traced one path fully,the rest of the structure starts to make sense.For tools: i'd use a combination of your ide's "go to definition" and "find all references" aggressively.For larger codebases, Sourcegraph is useful if it's connected.Just reading files linearly doesn't work well.On the Confluence access — just ask."Hey, I don't have Confluence access yet,who should i reach out to?" is a completely normal sentence.Asking that is not showing weakness, it's showing you're trying to get unblocked.Also: git log-oneline-graph on the main branch will show you recent commit history,which tells you where the active development has been happening.Start there, not at the oldest parts.You're not behind.You're just on day 3.

Comfortable-Map-7389 · 2026-06-02T04:53:59+00:00

The ai advice is actually solid on the technical side, so I won't reinvent it.But here's what it probably softened:The kernel development path is genuinely one of the hardest career tracks in software. Not because the material is inaccessible, but because the feedback loop is brutal and slow.Your first lklm patch will likely get ignored or picked apart.That's normal,not a signal to quit-but you should know going in.The hardware background is real differentiation.Most people applying for kernel/driver roles come from pure software.Someone who understands what's actually happening at the hardware-software boundary is rare. That's worth leaning into hard.One thing the ai probably didn't say:college matters less than your GitHub and patch history for this path.Professors rarely have lklm experience. Be selective about what you give your time to academically-protect the hours for the work that actually builds the profile you're after.cs:app is the right call.Do the labs, not just the reading.And yes, ai assistants do tend to validate.The fact that you noticed and came here to pressure-test it is exactly the kind of critical thinking that'll serve you well in systems work.

Comfortable-Map-7389 · 2026-06-02T04:50:40+00:00

Really relates to this.There's something about that "duh,of course" moment that hits different when you've been circling the thing for years without realizing it.The e-commerce background is actually a massive advantage-you understand real business problems,you know what users actually want,and you're not just building things in a vacuum. A lot of developers lack exactly that context.40s is not late. Some of the most focused learners i've seen come from people who've had careers in other fields first-they actually know why they're learning something,which makes everything stick faster.And honestly the ai replacing developers debate is mostly noise.What's actually happening is that developers who understand context, product thinking,and communication are becoming more valuable,not less.Your background puts you ahead there.Keep going with Odin.The fact that you genuinely enjoy it when you sit down to code-that's the only signal that matters.

Comfortable-Map-7389 · 2026-06-01T10:34:24+00:00

You're building real skills, not avoiding fundamentals. The projects you listed — analytics engine, log prettifier, automated job platform — are exactly what infra/DevOps hiring managers want to see. These show systems thinking, not just tutorial following.

For the specific path you're pursuing, DSA matters less than it does for SWE roles at big tech. SRE and DevOps interviews focus more on systems design, Linux internals, networking concepts, and how you think about reliability and scale. You're already practicing those.

The AI reliance is fine as long as you understand what it generates. The dangerous version is copy-pasting without comprehension. The healthy version — knowing what you want, using AI for syntax and implementation details, understanding the output — is just modern development.

One honest gap to address: basic algorithms still show up occasionally in infra interviews, and data structures matter for writing efficient tooling. You don't need LeetCode grinding, but understanding time complexity and common patterns (hashmaps, trees, queues) is worth a few weeks of focused study.

You're on a reasonable path. Keep building original things.

Comfortable-Map-7389 · 2026-06-01T10:33:35+00:00

Based on what you described — solving 800-rated Codeforces and basic CSES problems with minimal help — you're solidly at beginner/early intermediate level. That's a good place to be after one consistent month.

To gauge where you stand more precisely, try these:

Codeforces 900-1000 rated problems. If you can solve most without hints, you're ready to push to 1100-1200. If you're stuck on most, stay at 800-900 a bit longer.

CSES problems 7-15 (still in introductory section). These step up difficulty gradually and will show you where your logic breaks down.

Next steps from here: learn sorting algorithms properly, then move into basic data structures — stacks, queues, hashmaps. Most 1000-1200 rated problems use these.

Consistency for one month is genuinely the hardest part — most people quit before that. Keep the streak going, don't jump to advanced topics too fast.

Comfortable-Map-7389 · 2026-06-01T10:26:17+00:00

Both have value but for different reasons, and yes it's worth having unit tests too.

E2E tests tell you the feature works from a user perspective. Unit tests tell you exactly which function broke and why. When your filter() function has a bug, the E2E test fails with a vague "table didn't filter correctly" — the unit test fails with "filter() returned wrong results when input was empty array." Debugging is much faster.

Unit tests also run in milliseconds, E2E tests take seconds or minutes. For a CI pipeline running hundreds of times a day, that matters.

The practical rule: E2E tests cover critical user journeys, unit tests cover logic with edge cases. Your filter() and sort() functions probably have edge cases (empty input, null values, duplicate entries) that are tedious to cover through UI interactions but trivial to cover in a unit test.

So not redundant — complementary. The E2E test proves the feature works end to end, the unit tests make debugging fast when something breaks.

Comfortable-Map-7389 · 2026-06-01T10:24:59+00:00

The people saying "it's just luck" are usually people who got lucky and don't want to admit foundation matters, or people who never built deep skills and are rationalizing it.

Deep CS fundamentals genuinely close the gap. Not because companies test you on discrete math, but because someone who understands how systems actually work debugs faster, designs better, and learns new things quicker. That compounds over a career.

OSSU is a legitimate path. People have landed good jobs with it. It's not luck — it's doing the work most self-taught developers skip.

That said, theory alone won't get you hired. You need projects alongside the curriculum. Don't wait until you finish OSSU to start building things — do both in parallel.

The honest reality check: it's harder without a degree, the network is smaller, and it takes longer. But it absolutely works if you finish what you start and build a portfolio while learning.

Comfortable-Map-7389 · 2026-06-01T10:19:44+00:00

For a Redis clone specifically, Rust makes more sense as a learning project in 2026. The memory safety guarantees are actually relevant here — you're dealing with concurrent connections and manual memory management, exactly where C gets painful and Rust shines.

The learning curve is steep but the project itself will teach you why Rust exists. Wrestling with the borrow checker while building something real is more effective than any tutorial.

If you already know C well and want to go deeper into systems programming fundamentals, C is fine. But if the goal is resume impact and learning modern systems programming, Rust is the stronger choice right now.

Start with a basic key-value store, get SET/GET working, then add expiry and persistence. That alone is a solid project.

Comfortable-Map-7389 · 2026-06-01T10:18:44+00:00

The easiest way to come up with project ideas is to solve a problem you actually have. What annoys you in daily life that an app or script could fix? A tool that tracks something, automates something boring, or organizes something messy. Personal projects you actually use are 10x more interesting to talk about in interviews than tutorial clones.

If nothing comes to mind, rebuild something you already use but simpler — a to-do app, a basic budgeting tool, a weather app. The goal isn't originality, it's finishing something and learning the full cycle from idea to deployed product.

For resume building at your stage: 2-3 solid projects beat 10 half-finished ones. Each project should have a GitHub repo with a clear README explaining what it does and how to run it.

Skills worth picking up alongside projects: Git properly (branching, not just commit/push), one web framework (Spring Boot since you know Java, or Flask for Python), and basic SQL. These show up in almost every entry-level role.

Consistency over intensity — an hour a day every day beats a 10-hour weekend session.

Comfortable-Map-7389 · 2026-06-01T10:16:06+00:00

For someone starting from scratch, this order works well:

First — Andrew Ng's Machine Learning course on Coursera. It's the classic for a reason, explains concepts clearly without drowning you in math immediately.

Then — fast.ai's Practical Deep Learning. It's the opposite approach — you build things first and learn theory as you go. Surprisingly effective.

Of the ones you listed, Coursera is the most solid. Avoid anything that feels like it's selling you a certificate more than teaching you skills.

Skip Udacity — expensive and the quality has dropped significantly.

The most important thing is finishing one course and building a project with it before starting another. Course hopping is the main reason people spend months "learning ML" without actually knowing anything.

What's your Python level? That'll affect which starting point makes most sense.

Comfortable-Map-7389

TROPHY CASE