Development Standards & Team Workflow

• Never rush development. Focus on writing clean, maintainable, and scalable code rather than completing features quickly.
• Avoid unnecessary AI-generated or “vibe-coded” implementations. Always review, understand, and refine AI-generated code before using it.
• Code duplication is strictly prohibited. Before creating a new component, verify whether an existing component can be reused.
• Keep components modular and maintainable. As a general guideline, a single component should ideally contain 100–150 lines of code. If it becomes larger, consider splitting it into smaller reusable components.
• Prioritize reusable and dynamic components. Whenever possible, use props, configuration objects, or other dynamic approaches instead of creating multiple similar components.
• Aim for minimum code with maximum functionality by following DRY (Don’t Repeat Yourself) principles.

Before considering any component complete:

• Review the component thoroughly.
• Ensure there is no duplicated logic.
• Remove unnecessary code and optimize wherever possible.
• Confirm that the component is reusable and follows project standards.
• Once verified, commit the component with a meaningful commit message.

• Every developer must work only on their own feature branch.
• No one is allowed to push directly to the main branch.
• No one should merge their own branch unless it has been reviewed and approved.
• Merge requests (Pull Requests) must be reviewed before being merged.
• Merge conflicts are expected during development and can be resolved when necessary. They should never be a reason to bypass the branching workflow.

• Commit frequently with meaningful progress.
• Do not wait until an entire feature or service is completed before committing.
• Ideally, every completed component should have its own commit.
• For example, if a service contains 20 components, there should ideally be around 20 meaningful commits.
• Every commit message must clearly describe what has been implemented or changed so that any team member can easily understand the project history.

Documentation is as important as development. Every project should maintain:

• An updated README.md
• Well-structured JSON configurations wherever applicable
• Clear project structure
• Proper documentation for reusable components
• Configuration details for easier onboarding and maintenance

The goal is to make the project easy to understand for both current and future team members.

From now on, every project will follow a task-based workflow.

• Every developer will receive clearly defined tasks.
• Complete one assigned task before moving to the next.
• Avoid trying to complete an entire frontend, backend, database, or API in a single day.
• Focus on writing high-quality, maintainable code instead of finishing quickly.
• Development should always be component-based, reusable, dynamic, scalable, and professional.

Quality is always more important than speed.

• Every assigned task has a responsible owner.
• Complete your assigned task within the agreed timeline.
• Avoid working on another developer’s assigned task unless specifically requested or project timelines require additional support.

AI is a productivity tool—not a replacement for engineering judgment.

• Always write a detailed and well-structured prompt before using AI tools.
• Avoid vague prompts such as “Do this”, “Fix this”, or “Make it work”.
• Instead, provide complete project context, requirements, expected output, constraints, and coding standards.
• Well-written prompts reduce token usage, improve response quality, and minimize unnecessary iterations.
• Always review, validate, and optimize AI-generated code before committing it.

Code review is everyone’s responsibility.

• Every developer’s code should be reviewed.
• My code should be reviewed by the team.
• Your code will also be reviewed before approval.
• Feedback should be constructive and focused on improving code quality rather than criticizing individuals.

Our objective is to maintain a shared standard of excellence across the entire codebase.

For every project, we will follow these core principles:

Digital marketing work must stay transparent and measurable. Every marketer is expected to share clear progress updates as required by each project.

• Share progress reports for every active marketing project on the schedule agreed for that project.
• Submit weekly progress reports covering all work completed during the week — campaigns launched, content published, ads run, leads generated, and any blockers.
• Submit monthly progress reports summarizing overall performance, key metrics, results vs goals, and planned next steps.
• Reports must mention all progress clearly: what was done, what improved, what needs attention, and what is planned next.
• Include relevant supporting details such as analytics screenshots, campaign links, performance numbers, and client-facing updates when applicable.
• Keep communication proactive — do not wait to be asked for status. Share updates on time so the team and admin can track delivery.
• Align reporting format and frequency with the project requirements (some projects may need more frequent updates).

If the project requires additional reporting (daily check-ins, client decks, or campaign reviews), follow that project’s reporting plan in addition to the weekly and monthly reports.